New Topic: Policy Inputs

["Hal Lockhart" <hlockhar@bea.com>]

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