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

[Erik Rissanen <mirty@sics.se>]

Rich,

Thanks for the clarification. So you are basically looking for a way to
minimize the number of attributes that needs to be resolved since
attribute gathering might be expensive. I was afraid you wanted the PEP
to do magic and find unknown attributes. :-)

I would second, at least for now, Anne's comment in her email that this
is something better handled by the context handler than the PDP
request/response documents. It seems simpler to provide a callback which
the PDP can use to ask the context handler for an attribute as it needs
to, rather than collecting missing attributes in to the response. I
haven't thought much about it, but I would suspect that it is easier for
the PDP (or the policy author) to be clever about in which order to
evaluate policies to minimize attribute resolution, rather than
collecting all missing attributes that might potentially lead to a
permitted access decision.

Currenlty, the Request/Response define (in an abstract sense) the
interaction between the PEP and PDP, not between the PDP and the context
handler. There is a problem to treat this interaction for finding
missing attributes because the full policy has to be evaluated before a
Response can be produced and then the policy evaluation has the be
restarted from the beginning with the additional attributes. This is
overhead compared to resolving the attribute "just in time".

In the sunxacml implementation, which I am familiar with, there is an
interface called AttributeFinder which is used to implement this dynamic
attribute fetching. If I understand you correctly (including your
another email a moment ago), you would like to standardize this
interface. Right?

Best regards,
Erik


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