Re: [xacml] New Topic: Policy Inputs

[Prateek Mishra <prateek.mishra@oracle.com>]

Hal,

Thanks for your detailed response. Based upon the discussion here,
the two issues that i would be interested in following up further are:

(1) Characterizing the vocabulary, attributes types and values emitted 
by a PEP.
This was discussed on the Mar 1 conference call. I agree  that it would 
not be difficult to create
an initial draft for discussion.

(2) Investigate the feasibility of representing resource attributes in 
some standard form. 
This seems to me a harder and more open-ended topic.

- prateek


> 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
>
>