Re: [xacml] New Issue#66: XACML-Core 2.0,3.0 Missing attributes maybe underspecified

[Rich Levinson <rich.levinson@oracle.com>]

Hi Anne,

Thanks for the in depth feedback. I think I am beginning
to sense what may be the underlying issue that has been
causing me concern in this area.

One of the things I have been looking at is interoperability
and in particular interoperability wrt the request/response
"protocol", which I am interpreting as communication
between the ContextHandler and the PDP.

I am getting the impression that there is also a notion of
interoperability between the PEP and the ContextHandler,
but I don't believe there is anything in the XACML 2.0
spec that can be the basis of such a notion in any
rigorous manner.

I think the data flow diagram on p 17 figure 1 makes this
pretty clear: the PEP-CH protocol is steps 3 and 12, which
are specified in the data flow to be in "native request format".
Therefore I do not believe this spec provides the basis
for interoperability across the PEP-CH interface.

However, I do believe the spec provides the basis for
interoperability across the CH-PDP interface, in
particular, steps 4 and 11 in the diagram.

i.e. the notion of interoperability that I was considering
was one vendor's ContextHandler communicating with
another vendor's PDP.

It seems to me the implementation technology of these
2 modules is vastly different, with the PDP being focused
on policy evaluation and the ContextHandler being
focused on native<->canonical translations as well as
attribute gathering from myriad sources.

Therefore it seems reasonable to me that vendors would
have expertise in one or the other or both of these areas
and there would be some vendors bringing PDPs, some
vendors bringing Context Handlers etc. to an interoperability
event or an enterprise integration site.

Given that context for discussion, what I see as the
under-specification is the items 5 and 10 in the diagram,
which the emails have addressed by suggesting the Sun
AttributeFinder could provide the basis for this interface.

So, I guess the issue I am raising at the higher level is
to get clear on these concepts first: i.e. what are the
interoperability points for XACML-compliant
components.

Right now I am coming under the impression that
there may be some confusion between whether
interoperability is across the PEP-CH interface
or across the CH-PDP interface.

    Thanks,
    Rich


Anne Anderson wrote:
> "Missing Attribute" is a very difficult thing to determine except in 
> the context of actually evaluating XACML policies and requesting 
> "missing attributes" one by one as they are required for that evaluation.
>
> For example, consider two hypothetical Rules for permitting access to 
> a given resource:
>
>   Web-access-rule: cookie-value-authenticated="true"
>
>   Internal-application-access-rule: IP-address=<inside intranet>
>
> What are the "missing attributes" here?  It depends on knowing more 
> than just the resource-id.  If the Context Handler asks for both 
> "cookie-value-authenticated" and "IP-address", and the source is an 
> internal application that does not use cookies, then the PEP has no 
> way of knowing that the policy can be satisfied with certain values 
> for either attribute.  Should the PEP give up because it can't supply 
> all requested attributes?  Should the PEP assume that it should supply 
> as many of the requested attributes as possible, and that access might 
> be permitted then?  This may involve collecting tons of unnecessary 
> attributes.
>
> The "missing attributes" in the general case must be expressed as a 
> policy.  This policy can be at least mostly determined by "partially 
> evaluating" the original policy using the previously known 
> information, such as the subject-id, resource-id, and action-id.  All 
> policies and rules that do not match the key values can be eliminated, 
> and even conditions can be reduced to include only those that might be 
> applicable.  But we have never defined partial evaluation, and even if 
> we did, the result is still a "policy" that the PEP would have to 
> evaluate.  Why should the PEP have to do that when we have designed 
> PDPs to do policy evaluation?
>
> I think it would be quite reasonable to define a profile for a 
> protocol between the Context Handler and the PEP for doing callbacks 
> to obtain attributes as needed during evaluation.  This protocol 
> should not require that policy evaluation start over from scratch once 
> the missing attribute is supplied - it should be an extension to the 
> existing model for PDP<->Context Handler interaction.  The existing 
> Response with "missing attribute" is best viewed as a termination of 
> the existing evaluation with the message "access is not permitted, but 
> you can try another Request that includes these missing attributes".  
> If the PEP does submit another Request with the missing attributes, 
> the Context Handler and PDP treat it as an entirely new Request and 
> start evaluation of policies from the top.
>
> The Request is a model to express the full set of attributes available 
> to the PDP for evaluation, regardless of when or from where these 
> attributes are supplied.  The Request Context really is the model for 
> interaction between the PDP and the Context Handler.  Most current 
> implementations (I believe) use the Request schema as a concrete 
> protocol between the PEP and the PDP, but in this case the Request as 
> supplied by the PEP should be viewed as only a partial version of the 
> actual Request Context used by the PDP.
>
> I think the Sun XACML Attribute Finder modules correctly express the 
> intent of the specification: as the PDP encounters an Attribute 
> required to evaluate its policies, it requests the value of that 
> Attribute from the Context Handler.  This request is completely 
> independent of, although consistent with, the concrete Request 
> Context.  It is "as if" there were a Request Context that should 
> contain the Attribute and its value if it is available from any source.
>
> So if a protocol for requesting "missing attributes" from a PEP were 
> to be implemented, it should be based on something like Attribute 
> Finders.  Some Attributes might be requested from the PEP, while 
> others are requested from databases, registries, on-line attribute 
> authorities, etc.  For certain Attributes that the PEP is required to 
> supply, however, the Attribute Finders could be implemented to do a 
> callback to the PEP.  I don't think such a callback should be based on 
> the existing Response Context using the "missing attribute" error 
> value since a Response represents termination of an existing policy 
> evaluation - there is no state saved once a Response has been sent.
>
> My $.02
>
> Regards,
> Anne
>
> Rich Levinson wrote:
>
>> Hi Anne,
>>
>> It is my assumption that the request/response protocol is
>> "between" the ContextHandler and the PDP. i.e. the CH
>> prepares the RequestContext based on domain-specific
>> input from the PEP (ex. step 4 line 584 xacml 2.0 core spec)
>> then sends the request to the PDP. Presumably the
>> PDP evals the req and then would send the MissingAttributeDetail
>> back to the CH.
>>
>> Even from this perspective, the CH needs to understand the
>> vocabulary enough to know how to gather the attrs in step 5
>> line 585 core spec.
>>
>> I recognize that in this non-normative flow diagram in the core
>> spec that steps 5-11 are intended to be purposely left as
>> unspecified and the flow just given as a guideline, however,
>> from a design point of view it seems to me to make no
>> sense for the CH caller to have to invent some new
>> protocol to handle the intermediate steps, when the
>> mechanism already exists in the core spec for implementing
>> this very type of operation. As such, I think it is appropriate
>> that the core spec shed light on how this mechanism would
>> operate within the scope of the req/rsp protocol. It is in
>> that sense that I am saying the protocol is underspecified.
>> In particular, steps 5 and 10 appear to fit like a glove with
>> the normative functional mechanisms specified in section
>> 7.15.3 that talks about MissingAttributeDetail.
>>
>> In general, I think the CH is defined in the core spec as
>> a distinct module from the PDP. In some implementations,
>> a CH local to the PEP may very well be the PEP's mechanism
>> for issuing the calls to the PDP. And generally, in the case
>> of resource attrs, it is likely that the PEP is somewhat local to
>> the resource and an appropriate place for the CH to pass
>> the req for collection of the required missing attrs.
>>
>> Also, I am not viewing this as an "alternative" to profiling as
>> Erik asked, but I am viewing it as an appropriate aspect
>> of the profiling. i.e. based on the shared vocabulary of
>> attr identifiers it is up to the caller on the CH side to know
>> how to do the domain specific operations required to
>> obtain the identified attrs.
>>
>> It is in this context that I am saying the spec needs to address
>> issues such as how to tell the CH that the missing attr is a
>> subject attr as opposed to a resource attr. I believe the
>> protocol as currently specified is unbalanced in this regard
>> since these characteristics are an implicit part of the request context
>> but there is no means to specify them in the response context
>> that I have been able to determine (ex in Rule 2, (which I think
>> I misidentified in the previous email as Rule 1) a parent guardian
>> id needs to be supplied both as a subject attr and a resource attr,
>> each gathered separately, I would think it would be desirable
>> to specify this in the response since it is known in the policy that
>> the attr is subject or resource related and it seems reasonable
>> for missing attrs to say whether they are Subject, Resource,
>> Action, or Environment that are missing.).
>>
>>    Thanks,
>>    Rich
>>
>>    Thanks,
>>    Rich
>>
>>
>> Anne Anderson wrote:
>>
>>> Rich,
>>>
>>> Where there may be a variety of sets of attributes required to 
>>> satisfy policies, the typical design is for the PEP to send the key 
>>> values (subject-id, resource-id, action-id), and for remaining 
>>> attributes to be obtained from directly from repositories or on-line 
>>> attribute authorities by the XACML PDP's Context Handler as required 
>>> during policy evaluation.  The Context Handler could also make 
>>> call-backs to the PEP to obtain necessary attributes.
>>>
>>> For some XACML policies, it is possible to determine the sets of 
>>> attributes needed to satisfy a particular request, but for many 
>>> policies, such analysis is prohibitive if not impossible.
>>>
>>> Regards,
>>> Anne
>>>
>>> Rich Levinson wrote:
>>>
>>>> Hi Erik,
>>>>
>>>> The assumption I am making is that the PEP and PDP share a
>>>> vocabulary, which presumably can contain a long list of attribute
>>>> identifiers.
>>>>
>>>> For any given request, there is no way in advance for the PEP to
>>>> know exactly what subset of this vocabulary is required to meet
>>>> the needs of this particular request. It is only after the applicable
>>>> policies are selected by the PDP based on the initial resource
>>>> identification etc that the relevant attributes are identified that
>>>> would be required.
>>>>
Actually, I meant Rule 2 in the next para - Rich
>>>> For example, in the Rule 1 of  Example two, it is only after it is
>>>> known by the PDP that Rule 1 is an applicable policy that the
>>>> resource element patientDoB is required to evaluate the
>>>> request. It would be at this point that this attr would be
>>>> identified as missing to the PEP, that the PEP would know
>>>> it had to obtain this attr in order to satisfy the request.
>>>>
>>>> In general, there may be all kinds of Subject and Resource
>>>> attrs that are required for a particular request. It would,
>>>> in general, be prohibitive for a PEP to gather all possible
>>>> attrs from all possible sources to supply with every request.
>>>>
>>>> It is my assumption that this list of required attrs is only
>>>> known by the PDP determining the applicable policy and
>>>> then based on the attrs identified in the various rules, contained
>>>> in this dynamically determined applicable policy, if the
>>>> Subject is not granted access based on the info supplied,
>>>> there may be rules that within that policy that could not
>>>> be evaluated because some attrs were missing. The PDP
>>>> may at this point return Indeterminate and supply the
>>>> list of attrs needed to eval the request.
>>>>
>>>> In a recent email, Hal had a comment on this as well which may
>>>> provide further clarification:
>>>>
>>>>    http://lists.oasis-open.org/archives/xacml/200702/msg00059.html
>>>>
>>>>    "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. "
>>>>
>>>> Typical real world use cases can involve accessing external 
>>>> elements such as
>>>> credit scores from attribute providers, or possibly resource 
>>>> attributes such as
>>>> social security number associated with the requested record, etc. 
>>>> Information
>>>> such as this should not be gathered unless it is determined that it 
>>>> is required
>>>> to meet the needs of specific requests which only can be determined 
>>>> when
>>>> the applicable policy has been constructed by the PDP.
>>>>
>>>> Let me know if this helps or more clarification required.
>>>>
>>>>    Thanks,
>>>>    Rich
>>>>
>>>> Erik Rissanen wrote:
>>>>
>>>>> Rich,
>>>>>
>>>>> Could you clarify a couple of things about this issue? What do you 
>>>>> see
>>>>> at the intended use of the missing attribute details?
>>>>>
>>>>> I have always thought that for interoperability, the users of 
>>>>> XACML need
>>>>> to profile XACML. They need to specify the attribute vocabulary 
>>>>> which a
>>>>> PEP must provide in the request and policy writers may refer to.
>>>>>
>>>>> Do you intend to use the missing attribute details as a substitute 
>>>>> for
>>>>> profiling? That is, policy writers would refer to attributes, and PEP
>>>>> would dynamically try to find those attributes based on the missing
>>>>> attribute responses? How would the PEP find missing attributes it has
>>>>> not been programmed to know about? And if it knows about the 
>>>>> attributes,
>>>>> why did it not provide the attributes in the first place?
>>>>>
>>>>> Or is it something else you intend? (For instance submitting only a
>>>>> minimum set of attributes?)
>>>>>
>>>>> Best regards,
>>>>> Erik
>>>>>
>>>>>
>>>>> Rich Levinson wrote:
>>>>>  
>>>>>
>>>>>> I have added the following issue to the issues list:
>>>>>>
>>>>>>     http://wiki.oasis-open.org/xacml/IssuesList
>>>>>>
>>>>>> The point of the issue (below) is not to identify trivialities with
>>>>>> the example, but
>>>>>> to use the example as a basis for some general comments more toward
>>>>>> end of the issue description. It seemed to me that using the example
>>>>>> as context would be an effective way to raise the somewhat complex
>>>>>> issues/concerns that are the main point here. (I will be happy to
>>>>>> re-edit the issue if that makes sense after people have had a
>>>>>> chance to look at it).
>>>>>>
>>>>>>     Thanks,
>>>>>>     Rich
>>>>>>
>>>>>>
>>>>>>         66. Missing attributes may be underspecified
>>>>>>
>>>>>> I did a somewhat detailed analysis of "Example two" in the core spec
>>>>>> from the point of view of understanding how fine grained 
>>>>>> authorization
>>>>>> (fga) (applying resource attrs to az decision) was implemented and
>>>>>> came across a number of items that I think need to be addressed
>>>>>> especially in potential interoperability situations. I will put 
>>>>>> all in
>>>>>> one issue initially, we can decide if it needs to be broken out 
>>>>>> later.
>>>>>>
>>>>>> 1. line 1090-91 describing ResourceContent </xacml/ResourceContent>.
>>>>>> In both the core spec and the sample messages, the ResourceContent
>>>>>> </xacml/ResourceContent> contains the following:
>>>>>>
>>>>>>     * <ResourceContent </xacml/ResourceContent>>
>>>>>>           o <md:record xmlns:md="urn:med:example:schemas:record"
>>>>>>                 + 
>>>>>> xsi:schemaLocation="urn:med:example:schemas:record 
>>>>>>                   http:www.med.example.com/schemas/record.xsd">
>>>>>>                   
>>>>>> <http:www.med.example.com/schemas/record.xsd%22%3E>
>>>>>>                 + <md:patient>
>>>>>>                       # <md:patientDoB>1992-03-21</md:patientDoB>
>>>>>>                         
>>>>>> <md:patient-number>555555</md:patient-number>
>>>>>>                   </md:patient>
>>>>>>             </md:record>
>>>>>>       </ResourceContent </xacml/IssuesList/ResourceContent>>
>>>>>>       <Attribute AttributeId
>>>>>>       
>>>>>> </xacml/AttributeId>="urn:oasis:names:tc:xacml:1.0:resource:resource-id" 
>>>>>>
>>>>>>       DataType </xacml/DataType>="xs:string">
>>>>>>           o <AttributeValue </xacml/AttributeValue>>
>>>>>>                 + //med.example.com/records/bart-simpson.xml#
>>>>>>                   xmlns(md=
>>>>>>                   http:www.med.example.com/schemas/record.xsd)
>>>>>>                   xpointer(/md:record/md:patient/md:patientDoB)
>>>>>>             </AttributeValue </xacml/IssuesList/AttributeValue>>
>>>>>>       </Attribute>
>>>>>>
>>>>>> While I recognize that the example itself is not intended to be
>>>>>> perfect, it provides a convenient context for raising the following
>>>>>> questions/issues, especially wrt fga.
>>>>>>
>>>>>>   1.
>>>>>>
>>>>>>       If this is a first request from a PEP, why is the PEP 
>>>>>> supplying
>>>>>>       patient-number on line 1056? This looks like a required 
>>>>>> attr to
>>>>>>       evaluate Rule 1 (line 1141), if the requestor is the patient,
>>>>>>       but this example the requestor is the physician.
>>>>>>
>>>>>>          *
>>>>>>
>>>>>>             The physician-id is supplied in the request (line 1044),
>>>>>>             but the only rule it appears in is rule 3 (line 1522).
>>>>>>             This rule only allows "write" access (line 1507), so I
>>>>>>             expect this request would probably fail as it is 
>>>>>> currently
>>>>>>             set up. i.e. we would need to add a "read" action to 
>>>>>> rule
>>>>>>             3 or add a physician-id test to rule 1.
>>>>>>
>>>>>>    *
>>>>>>
>>>>>>       b. Assuming the above request fails, let's consider what might
>>>>>>       be done. There was a "read" request issued (line 1072), so 
>>>>>> that
>>>>>>       would mean that rule 1 (line 1182), rule 2 (line 1347), or 
>>>>>> rule
>>>>>>       4 (line 1668) could be applied.
>>>>>>
>>>>>> Rule 1 requires a Subject attribute patient-number (line 1134) to
>>>>>> match the patient-number in the requested resource record (line 
>>>>>> 1141).
>>>>>> Presumably a <MissingAttributeDetail 
>>>>>> </xacml/MissingAttributeDetail>>
>>>>>> could be returned, somehow identifying these 2 attributes to the 
>>>>>> PEP.
>>>>>>
>>>>>> Rule 2 requires a patientDoB resource attr (line 1297), a
>>>>>> parent-guardian-id subject attr (line 1363), and a parentGuardianId
>>>>>> resource attr (line 1371). Similarly a <MissingAttributeDetail
>>>>>> </xacml/MissingAttributeDetail>> could be returned requesting these.
>>>>>>
>>>>>>    *
>>>>>>
>>>>>>       Assuming this to be the case, one question I have is how does
>>>>>>       the <MissingAttributesDetail </xacml/MissingAttributesDetail>>
>>>>>>       tell the PEP whether the attributes that are missing should be
>>>>>>       resubmitted as part of the Subject or as part of the Resource?
>>>>>>       This info is provided in the Request from the xml structure,
>>>>>>       however, the <MissingAttributeDetail
>>>>>>       </xacml/MissingAttributeDetail>> does not have equivalent
>>>>>>       structure to make such distinctions.
>>>>>>
>>>>>> The above is intended just to give an example of questions that 
>>>>>> occur
>>>>>> for this particular example, but it is my opinion that it is
>>>>>> symptomatic of a general problem of how PEPs are supposed to know 
>>>>>> how
>>>>>> to construct the proper RequestContext </xacml/RequestContext>
>>>>>> necessary, in general, for complex scenarios that require 
>>>>>> substantive
>>>>>> fga attrs.
>>>>>>
>>>>>> In these more complex fga scenarios it is likely that
>>>>>> <MissingAttributeDetail </xacml/MissingAttributeDetail>> will be
>>>>>> typically needed to collect all the required attributes. 
>>>>>> Therefore, I
>>>>>> believe some more robust mechanisms, possibly using
>>>>>> MissingAttributeDetail </xacml/MissingAttributeDetail> as a good
>>>>>> starting point will be needed to adequately define operation in this
>>>>>> area.
>>>>>>
>>>>>> In this context as well, it is likely that xpaths are probably 
>>>>>> not the
>>>>>> way to go since they are only applicable to certain types of 
>>>>>> resources
>>>>>> (xml-based) and those resource structures are likely to change in
>>>>>> time, and these changes should not percolate into the enterprise
>>>>>> Policy arena. Therefore, mechanisms such as vocabularies should be
>>>>>> recommended usage here with the PEP being responsible for mapping 
>>>>>> the
>>>>>> vocabulary item to the particular resource physical access path such
>>>>>> as the xpath.
>>>>>>
>>>>>> CHAMPION: Rich
>>>>>>
>>>>>> Status: *OPEN*
>>>>>>
>>>>>>     
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>
>>>>
>>>>
>>>
>