[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New Issue#66: XACML-Core 2.0,3.0 Missing attributes may beunderspecified
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. > > 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* >>> >>> >> >> >> >> > > -- Anne H. Anderson Anne.Anderson@sun.com Sun Microsystems Labs 1-781-442-0928 Burlington, MA USA
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]