[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New Topic: Policy Inputs
Prateek has posed the following questions: How does the context handler obtain needed additional attributes for Resources, Subject, Environment? How to distinguish between attributes originating from the PEP vs. additional attributes needed for policy evaluation? Under what conditions does the PDP and PEP participate in a multi-step interaction? (4) Is there a standard way for the context handler to access resource meta-data? -------------- There is a fundamental conflict which was discussed in the XACML TC in the early days, but has essentially been ignored since. The conflict is that by design, only the PDP needs to know what is in policies. In particular it is undesirable architecturally for the PEP (or any other software component) to have to understand policies. The PAP needs to be able to create schema-correct policies, but not understand their semantics. Only a human administrator (or an intelligent policy creation agent, which falls outside the scope of the XACML architecture) needs to have the same understanding as the PDP. However, the implication of this architectural separation is that no one but the PDP knows what data will be required in order to evaluate the applicable policies. In fact in a sense, the PDP doesn't know until the evaluation begins. The theoretical answer is that the PDP should have access to all the available data relevant to the entities of the request. But this ignores the fact that gathering policy inputs has a cost. One type of cost is resource cost, where gathering unnecessary data increases latency or consumes cpu. Another cost is user inconvenience, such as the case where users are required to use a more secure form of authentication for some requests than others. It is desirable not to force the user to perform the extra authentication step unless it is truly required. Generally the tradeoff between insuring the necessary data is present and avoiding extra costs was judged by the TC to be highly specific to the environment in which the PEP, context handler and PDP exist. For this reason the required mechanisms and pattern of interaction have been left largely unspecified to date. There are two features of XACML which are intended to allow implementations to address this issue to some extent. First, XACML specifies that the order of evaluation of rules and policies is unspecified and the evaluation may terminate at any point once the result can be determined. This allows optimization of processing, but more importantly it allows the PDP to attempt to determine if access is allowed using the information that is already on hand. The second feature is the <MissingAttributeDetail> element in the Response context. (see section 6.16 of the XACML 2.0 spec) This allows the PDP to indicate that it could not make a decision because of one or more missing attribute. I don't know if any implementations actually make use of this feature. Returning to the original questions: >How does the context handler obtain needed additional attributes for >Resources, Subject, Environment? Architecturally speaking, the context handler gathers all the data required for the decision and puts it in the request context or equivalent data structure. (XACML does not require that the request context be instantiated as an XML document in memory or anywhere else, only that the result of policy evaluation is the same. This means if the data is already in some local format that the PDP understands, no conversion to XML is required.) The context handler is free to obtain the data from the PEP or any other source. It might do this by using standards such as SAML, LDAP, or SQL. In my own experience, data from these sources tends to be in highly environment-specific form. The TC has never attempted to profile the use of these standards, but tat is certainly a possibility. >Is there a standard way for the context handler to access resource >meta-data? I assume you are referring to Resource Attributes. No such scheme has been specified. The data might be located with the resource or even be part of the resource content. For example, I believe there may be some standards used in MAC systems where information is tagged with properties such as classification level. Alternatively the attributes could reside in a distinct repository. This would seem to introduce potential synchronization issues. Perhaps RDF or OWL could play a role in representing Resource Attributes. BEA is interested in specifying more in this area. >How to distinguish between attributes originating from the PEP vs. >additional attributes needed for policy evaluation? I believe the long discussion above addresses this. In general there is no reason to distinguish the sources of information per se, as long as they are trusted. >Under what conditions does the PDP and PEP participate in a multi-step >interaction? Largely unspecified by XACML. Believed to be highly specific to the environment. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]