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