[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]