[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
Hi Rich, I still think that a ID reference is simpler than digging up the datatype, attribute id and possibly issues, and going through all the attributes in the request section looking for nested elements containing matches for all two/three values. Also it's more verbose, making it more difficult to read by humans (for debugging, development, audit, etc) and means less data to move around. Regards, erik Rich.Levinson wrote: > Hi Erik, > > I see your point. How about if we constructed ListReference as follows: > > 1. Normal single element in category case: > * <ListReference Category="cat1"/> > 2. Multiple element in category case: > * <ListReference Category="cat2"> > <Attribute AttributeId="xxx" Issuer="yyy" > DataType="datatype"> > <AttributeValue>zzz</AttributeValue> > </Attribute> > </ListReference> > > With this approach typical case would be just match Category. > Multi-case would be match Category and contained Attribute w value. > Then Attr would only be synthetic in the extreme case as described in: > http://lists.oasis-open.org/archives/xacml/200901/msg00049.html > > Thanks, > Rich > > > > Erik Rissanen wrote: >> Hi Rich and all, >> >> This sounds good to me, except that I don't like the use of the >> synthetic id as the reference in the decision list. This forces all >> requests to contain synthetic ids, which I think are not needed in >> most cases, and is also more difficult to parse for a pre-processor >> since the id is more deeply nested. >> >> Regards, >> Erik >> >> Rich.Levinson wrote: >>> Hi Erik, Hal, and TC, >>> >>> There have been a lot of emails on this issue so far, but I think we >>> are at the point where all the ambiguities and potential missing >>> pieces have been accounted for, so I will try to summarize where I >>> think the proposal currently stands. >>> >>> First of all here are some reference emails that have examples that >>> show different aspects of the proposed solution: >>> >>> * example request with XPath (in Erik's most recent email (below)) >>> which is purported to return multiple nodes (an example response >>> would be helpful to augment this: >>> o >>> http://lists.oasis-open.org/archives/xacml/200901/msg00053.html >>> * example request with decision lists (Hal's most recent email) >>> (ignore the CorrelationId, because as Erik showed, it will not >>> work w XPath) >>> o >>> http://lists.oasis-open.org/archives/xacml/200901/msg00051.html >>> * example request showing multiple <Attributes> elements having >>> same @Category and using "synthetic attribute" with >>> "...multiple-request:unique-id" (would be useful to have >>> corresponding response showing returned "disambiguated" >>> <Attributes> elements >>> o >>> http://lists.oasis-open.org/archives/xacml/200901/msg00049.html >>> * example response showing 5 distinct results, not using synthetic >>> attribute, but using "...resource:resource-id" for Result >>> correlation. (This shows the important concept that not only is >>> the <Attribute> with the @IncludeInResult returned, but also its >>> parent <Attributes> element with the @Category.) >>> o >>> http://lists.oasis-open.org/archives/xacml/200901/msg00045.html >>> * original example request w DecisionList and w follow-up minor >>> correction >>> o >>> http://lists.oasis-open.org/archives/xacml/200901/msg00015.html >>> o >>> http://lists.oasis-open.org/archives/xacml/200901/msg00035.html >>> >>> Based on the analysis that has been done, I have a few >>> recommendations that, at least to me, appear to be important enough >>> to itemize as suggestions for the specifications. >>> >>> For the 3.0 Core spec: >>> >>> 1. It became inferentially apparent that a fundamental "rule" is >>> that a Request context that is processed by the PDP must have at >>> most 1 <Attributes> element with a specific Category. I >>> recommend that this be explicitly stated in section 5.35 in the >>> description of the <Attributes> [One to Many] element. What is >>> there now is not unambiguous in this regard, and I recommend it >>> be tightened up. >>> 2. Similarly, I think explicit text should be in Section 5.37 for >>> the Category [Required] description. i.e. specify that while >>> multiple <Attributes> elements with the same Category are >>> allowed in the Request element, that for the purpose of making >>> an authorization decision, only one <Attributes> element per >>> Category is allowed. >>> 3. Section 5.39 under explanation of IncludeInResult [Default >>> false] I recommend that when included in Result the Attribute >>> will be parented by its <Attributes w @Category> element. Also >>> if multiple <Attribute> elements within one Category are tagged, >>> then they will share the parent. >>> 4. Section 5.41 under explanation of <Attributes> element, I >>> recommend that it be explicitly stated that there will be one >>> <Attributes> element for each @Category in the Request that >>> contained an @IncludeInResult. >>> >>> For the 3.0 Multi-Decision spec: >>> >>> 1. I recommend that at least for the multi-Attributes @Category >>> mechanism that a clear explanation be included that without >>> DecisionLists, that there is an inferential n-dimensional >>> cross-product applied, where n is the number of @Categories >>> that have multiple <Attributes> elements within the Request. >>> So, for example if there are 3 Category attrs, say cat1, cat2, >>> cat3 that occur in multiple <Attributes> elements, for example >>> let's say there are 4 <Attributes> elements w cat1, 4 with cat2, >>> and 3 w cat3, then there will inferentially be 4x4x3 = 48 >>> individual Requests generated to the PDP, each of which will >>> have a Result element in the Response. It would also be worth >>> noting that if there are additional single element Category >>> attrs, say cat4, cat5, and cat6, that the <Attributes> element >>> for each of those Category attrs will be evaluated in all 48 >>> decisions. i.e. all 48 decisions will be based on >>> cat1,cat2,cat3,cat4,cat5,cat6, where 4,5,6 remain constant thru >>> the process and 1,2,3 are incremented as if to visit every cell >>> in a 4x4x3 3-dimensional matrix in this particular example. >>> 2. I recommend that the DecisionLists mechanism be introduced as an >>> augmentation to the n-dimesional matrix in 1 above. i.e. given >>> the 48 decisions above, I think that DecisionLists can be used >>> to pare down the list so that the full n-dimensional cross >>> product does not get evaluated. i.e. The DecisionLists would >>> override the inferential processing if they were present. >>> * For example, if we really didn't want the 4x4 portion >>> above but were really interested in 2 2x2 portions, there >>> could be 2 DecisionLists up front that contained the >>> following elements: >>> o >>> cat11,cat12,cat21,cat22,cat31,cat32,cat33,cat4,cat5,cat6 >>> o >>> cat33,cat34,cat43,cat44,cat31,cat32,cat33,cat4,cat5,cat6 >>> * Each of the above DecisionLists would produce 2x2x3 = 12 >>> results for a total of 24 results. >>> * i.e. the suggestion is that the presence of DecisionLists >>> simply override the inferential multiple effect of the >>> <Attributes> elements themselves and transfer the >>> inferential effect to the multiple category instances w >>> same category to within each list. >>> * i.e. the presence of the DecisionLists would effectively >>> say: regard the actual <Attributes> elements as a pool of >>> referencable entities and process the request as if >>> multiple Request elements had come in with <Attributes> >>> elements listed in the DecisionList, and process >>> inferentially on that basis. Everything would be returned >>> in a single response. >>> 3. The only lingering "annoyance" is that the DecisionLists address >>> the <Attributes> elements by the xml:id, whereas within the >>> inferential processing we need to reference for correlation >>> purposes based on an internal IncludeInResult attribute. This is >>> not a show-stopper of any sort, but it does appear that there >>> are 2 mechanisms effectively used to identify the same >>> <Attributes> element. A couple of considerations: >>> * It would seem that xml:id for <Attributes> elements that >>> only had a single instance is more than is needed since >>> one could theoretically simply identify these single >>> instance elements by identifying their Category value. >>> * It seems that what's needed for the DecisionLists that are >>> going to use multiple <Attributes> elements with the same >>> Category is something within the <Attributes> element that >>> distinguishes it from the other <Attributes> elements of >>> the same Category. This seems to be deja vu all over again >>> (sic) wrt the analysis that left us with the "synthetic >>> attributes" as the ultimate decider for those cases where >>> nothing else would work >>> >>> http://lists.oasis-open.org/archives/xacml/200901/msg00049.html >>> * Therefore, I am tentatively suggesting that a usable >>> alternative to URI,xml:id might be @Category.value(index), >>> where "index" would be the value of a synthetic attribute >>> within the <Attributes @Category> element with >>> AttributeId="...multiple-request:unique-id". >>> >>> I believe everything above, is essentially pretty much identifying >>> what has already been decided and putting it all in one place, at >>> least wrt 3.0 Core spec, plus I think that comment 1 for >>> multi-decision is simply stating what has already been agreed, >>> comment 2 is some clarification on how DecisionLists could be viewed >>> and used, and comment 3 admittedly is something "new" to address >>> what appears to me to be a lingering "rough spot" in what has been >>> decided so far. >>> >>> Comments and suggestions are welcome. >>> >>> Thanks, >>> Rich >>> >>> >>> Erik Rissanen wrote: >>>> Hi Hal, >>>> >>>> I just realized that the CorrelationId will not work, and we need >>>> the IncludeInResult. >>>> >>>> The existing 2.0 multiple resource profile defines a few more modes >>>> of multiple requests than multiple <Resource> elements. For >>>> instance, it is possible to specify multiple request in the form of >>>> an xpath expression on the <ResourceContent>, where each node the >>>> xpath matches will generate an individual request. Like this for >>>> instance: >>>> >>>> 2 <Request >>>> 3 xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" >>>> 4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>>> 5 xmlns:md="http://www.medico.com/schemas/record"; >>>> 6 >>>> xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os" >>>> 7 >>>> xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os >>>> 8 access_control-xacml-2.0-context-schema-os.xsd"> >>>> 9 <Subject> >>>> 10 <Attribute >>>> 11 >>>> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" >>>> 12 DataType="http://www.w3.org/2001/XMLSchema#string";> >>>> 13 <AttributeValue>Julius Hibbert</AttributeValue> >>>> 14 </Attribute> >>>> 15 </Subject> >>>> 16 <Resource> >>>> 17 <ResourceContent> >>>> 18 <md:record> >>>> 19 <md:patient_info> >>>> 20 <md:name>Bart Simpson</md:name> >>>> 21 <md:age>60</md:age> >>>> 22 <md:sex>male</md:sex> >>>> 23 >>>> <md:health_insurance>123456</md:health_insurance> >>>> 24 </md:patient_info> >>>> 25 <md:diagnosis_info> >>>> 26 <md:diagnosis> >>>> 27 <md:item type="primary">Gastric >>>> Cancer</md:item> >>>> 28 <md:item type="secondary">Hyper >>>> tension</md:item> >>>> 29 </md:diagnosis> >>>> 30 <md:pathological_diagnosis> >>>> 31 <md:diagnosis> >>>> 32 <md:item type="primary">Well >>>> differentiated adeno carcinoma</md:item> >>>> 33 </md:diagnosis> >>>> 34 <md:date>2000-10-05</md:date> >>>> 35 <md:malignancy type="yes"/> >>>> 36 </md:pathological_diagnosis> >>>> 37 </md:diagnosis_info> >>>> 38 </md:record> >>>> 39 </ResourceContent> >>>> 40 <Attribute\r >>>> 41 >>>> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" >>>> 42 DataType="http://www.w3.org/2001/XMLSchema#string";> >>>> 43 >>>> <AttributeValue>*[local-name()='Resource'][namespace-uri()='urn:oasis:names:tc:xacml:2.0:context:schema:os']/*[local-name()='ResourceContent'][namespace-uri()='urn:oasis:names:tc:xacml:2.0:context:schema:os']/*[local-name()='record'][namespace-uri()='http://www.medico.com/schemas/record']/*[local-name()='patient_info'][namespace-uri()='http://www.medico.com/schemas/record']/*[self::*[local-name()='name'][namespace-uri()='http://www.medico.com/schemas/record'] >>>> or >>>> self::*[local-name()='age'][namespace-uri()='http://www.medico.com/schemas/record']]/descendant-or-self::node()</AttributeValue> >>>> >>>> 44 </Attribute> >>>> 45 <Attribute >>>> 46 >>>> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:scope" >>>> 47 DataType="http://www.w3.org/2001/XMLSchema#string";> >>>> 48 <AttributeValue>XPath-expression</AttributeValue> >>>> 49 </Attribute> >>>> 50 </Resource> >>>> 51 <Action> >>>> 52 <Attribute >>>> 53 >>>> AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" >>>> 54 DataType="http://www.w3.org/2001/XMLSchema#string";> >>>> 55 <AttributeValue>read</AttributeValue> >>>> 56 </Attribute> >>>> 57 </Action><Environment/></Request> >>>> >>>> From this request there will be multiple results, but there is only >>>> one <Resource> element. Each result will contain a specific >>>> ResourceId XML attribute for correlation purposes. >>>> >>>> In the corresponding 3.0 multiple request, it will be necessary to >>>> use the IncludeInResult since there are not multiple Attribute >>>> elements, which could be used for correlation, even if they had a >>>> CorrelationId. >>>> >>>> So I think we should drop the CorrelationId proposal, and if >>>> necessary, people will have to use a synthetic XACML attribute for >>>> correlation. >>>> >>>> Best regards, >>>> Erik >>>> >>>> >>>> Hal Lockhart wrote: >>>>> As of today's meeting I believe we are down to deciding how to do >>>>> correlation. The alternative previously proposed is to use the >>>>> IncludeInResponse mechanism. This may involve submitting synthetic >>>>> attributes, not referenced by policy, simply to correlate requests >>>>> and decisions. >>>>> >>>>> The new idea (at least to me) is to move my previously proposed >>>>> XML Attribute - CorrelationID - to the <Attributes> element >>>>> instead of having it in the <DecisionList> element. >>>>> >>>>> This seems clearer to me, but others should express their >>>>> opinions. The new scheme would look something like this: >>>>> >>>>> <Request> >>>>> >>>>> <DecisionLists> >>>>> >>>>> <DecisionList> >>>>> >>>>> <ListReference URI="Sub1"/> >>>>> >>>>> <ListReference URI="Env"/> >>>>> >>>>> <ListReference URI="Res1"/> >>>>> >>>>> <ListReference URI="Act1"/> >>>>> >>>>> >>>>> </DecisionList> >>>>> >>>>> >>>>> <DecisionList> >>>>> >>>>> <ListReference URI="Sub1"/> >>>>> >>>>> <ListReference URI="Sub2"/> >>>>> >>>>> <ListReference URI="Env"/> >>>>> >>>>> <ListReference URI="Res2"/> >>>>> >>>>> <ListReference URI="Act2"/> >>>>> >>>>> </DecisionList> >>>>> >>>>> >>>>> <DecisionList> >>>>> >>>>> <ListReference URI="Sub3"/> >>>>> >>>>> <ListReference URI="Env"/> >>>>> >>>>> <ListReference URI="Res1"/> >>>>> >>>>> <ListReference URI="Act2"/> >>>>> >>>>> </DecisionList> >>>>> >>>>> >>>>> <DecisionList ... > >>>>> ... >>>>> >>>>> </DecisionList> >>>>> >>>>> >>>>> </DecisionLists> >>>>> >>>>> >>>>> <Attributes Category="Access_Subject" XML:Id="Sub1" >>>>> CorrelationId="FirstSubject"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> <Attributes Category="Intemediary_Subject" XML:Id="Sub2" >>>>> CorrelationId="SecondSubject"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> >>>>> <Attributes Category="Intemediary_Subject" XML:Id="Sub3" >>>>> CorrelationId="ThirdSubject"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> <Attributes Category="Environment" XML:Id="Env"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> <Attributes Category="Resource" XML:Id="Res1" >>>>> CorrelationId="FirstResource"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> >>>>> <Attributes Category="Resource" XML:Id="Res2" >>>>> CorrelationId="Secondresource"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> <Attributes Category="Action" XML:Id="Act1" >>>>> CorrelationId="FirstAction"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> <Attributes Category="Action" XML:Id="Act2" >>>>> CorrelationId="SecondAction"> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> <Attribute> >>>>> ... >>>>> </Attribute> >>>>> >>>>> </Attributes> >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> </Request> >>>>> >>>>> >>>>> Hal >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>> >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]