[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
Hi Erik, I am now a little confused. The only reason that Attribute gets added to DecisionList is to disambiguate multiple instances of the same Category. I thought you said in previous email that CorrelationId could not be used for this purpose and that we needed to use IncludeInResult: http://lists.oasis-open.org/archives/xacml/200901/msg00053.html Thanks, Rich Erik Rissanen wrote: > Hi again Rich, > > There is one more problem. Not all XACML data types have a defined > equality function. So it wouldn't work in all cases. > > Regards, > Erik > > Erik Rissanen wrote: >> 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 >> >> >> --------------------------------------------------------------------- >> 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]