xacml — archive

[Hal Lockhart]

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