[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
Hi Erik, I still believe there is potential ambiguity if there are multiple Resource (or other) elements w same resource-id but different accompanying attributes. For example you might want to test what decisions come back based on varying sets of attrs accompanying the same resource-id. The point is that the combination of category and any contained attribute values is not guaranteed to be unique in a multi-request. I think the only way to guarantee uniqueness is to assign unique identifiers to each instance of an Attributes element with common CategoryId in a given request and return these identifiers in the response generated from the decision where the instance was used. Thanks, Rich Erik Rissanen wrote: 49780C54.7050406@axiomatics.com" type="cite">Hi Hal, The IncludeInResult returns also the attribute category, so what you describe is not an issue. See the example below. Best regards, Erik 2 <xacml-ctx:Response xmlns:xacml-ctx="urn:oasis:names:tc:xacml:3.0:core:schema:wd-06"> 3 <xacml-ctx:Result> 4 <xacml-ctx:Decision>Permit</xacml-ctx:Decision> 5 <xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> 6 <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true"> 7 <xacml-ctx:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/MargeSimpson</xacml-ctx:AttributeValue> 8 </xacml-ctx:Attribute> 9 </xacml-ctx:Attributes> 10 <xacml-ctx:Status> 11 <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> 12 </xacml-ctx:Status> 13 </xacml-ctx:Result> 14 <xacml-ctx:Result> 15 <xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision> 16 <xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> 17 <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true"> 18 <xacml-ctx:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/LisaSimpson</xacml-ctx:AttributeValue> 19 </xacml-ctx:Attribute> 20 </xacml-ctx:Attributes> 21 <xacml-ctx:Status> 22 <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> 23 </xacml-ctx:Status> 24 </xacml-ctx:Result> 25 <xacml-ctx:Result> 26 <xacml-ctx:Decision>Permit</xacml-ctx:Decision> 27 <xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> 28 <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true"> 29 <xacml-ctx:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/HomerSimpson</xacml-ctx:AttributeValue> 30 </xacml-ctx:Attribute> 31 </xacml-ctx:Attributes> 32 <xacml-ctx:Status> 33 <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> 34 </xacml-ctx:Status> 35 </xacml-ctx:Result> 36 <xacml-ctx:Result> 37 <xacml-ctx:Decision>Permit</xacml-ctx:Decision> 38 <xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> 39 <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true"> 40 <xacml-ctx:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/BartSimpson</xacml-ctx:AttributeValue> 41 </xacml-ctx:Attribute> 42 </xacml-ctx:Attributes> 43 <xacml-ctx:Status> 44 <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> 45 </xacml-ctx:Status> 46 </xacml-ctx:Result> 47 <xacml-ctx:Result> 48 <xacml-ctx:Decision>NotApplicable</xacml-ctx:Decision> 49 <xacml-ctx:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"> 50 <xacml-ctx:Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" IncludeInResult="true"> 51 <xacml-ctx:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/MaggieSimpson</xacml-ctx:AttributeValue> 52 </xacml-ctx:Attribute> 53 </xacml-ctx:Attributes> 54 <xacml-ctx:Status> 55 <xacml-ctx:StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/> 56 </xacml-ctx:Status> 57 </xacml-ctx:Result> 58 </xacml-ctx:Response> Hal Lockhart wrote:On the last call I agreed we should drop the idea of an XML Attribute called CorrelationId as a means to correlate requests and responses. The idea discussed on the call was to use the previously proposed scheme of marking selected XACML Attributes with the XML Attribute "IncludeInResponse", thus causing the PDP to echo back their values in the Response. I expressed concerned about the fact that, especially when specifying subjects, there might be no attribute present which uniquely identifies an entity. Eric suggested that if necessary the PEP could provide "synthetic" XACML Attributes which would not be referenced by policy, but could be used to perform correlation. After thinking about this further, I think there is still a problem. Suppose we have two subjects Jack and Jill. Jill is a Doctor and Jack is a Nurse. Suppose we want to test access in 2 cases, with each as Access Subject (AS) and the other as Recipient Subject (RS) categories, holding Env, Resource and Action constant. In other words, the cases are: AS=Jack Role=Nurse RS=Jill Role=Doctor Env Res Act AS=Jill Role=Doctor RS=Jack Role=Nurse Env Res Act Obviously if we simply ask to have Role (Doctor or Nurse) returned, we will not be able to distinguish between the two cases above. However even if we add a synthetic attribute, such as Name (Jack or Jill), we still cannot distinguish the two cases. (since order has no significance) What is required is that the synthetic attribute values also reflect the subject category. (Or more generally the category, since XACML does not rule out the possibility that different categories may share the same attributes) So if we add a name Attribute to the <Attributes> elements, we must chose values like "Jack-AS", " Jack-RS", "Jill-AS", "Jill-RS", so we can distinguish the cases. I have also found a number of cases where technically there is no ambiguity in correlating the responses to the requests, but in practice the processing will be greatly simplified by using synthetic attributes with judiciously chosen values. My conclusion is that the scheme we agreed on during the meeting is workable, but we need to include text which discusses the issues concerning unambiguous and efficient correlation. Please tell me if my analysis is correct or if there are other problematic cases I have not considered. Hal-----Original Message----- From: Hal Lockhart [mailto:hal.lockhart@oracle.com] Sent: Thursday, January 15, 2009 9:30 AM To: hal.lockhart@oracle.com; xacml@lists.oasis-open.org Subject: RE: [xacml] Multiple Decison Request Proposal Rich's recent comment (which I agree with) drew my attention to a mistake I made in my original message. It was my intention that all the elements within <DecisionList> be the same, i.e. <ListReference>. Because of an editing error, one of them is <ActionReference> in the example. Hal-----Original Message----- From: Hal Lockhart [mailto:hal.lockhart@oracle.com] Sent: Wednesday, January 14, 2009 1:12 AM To: xacml@lists.oasis-open.org Subject: [xacml] Multiple Decison Request Proposal Last Thursday I promised to propose a scheme asking for multipledecisionsin a single request. It was agreed that a request could specifyarbitrarycombinations of attribute categories (with no duplicates), but that the actual attribute values would only be specified once. The scheme wouldnotrequire the entire cross product of all combinations to be used, but rather specific combinations could be specified. After thinking about it for a bit, I concluded the following. 1. I would propose a prefix of lists of items to be used in decisions as we previously discussed. This list uses references to XML Id Attributestoindicate which set of attributes to use. 2. Since all categories could be specified (not just Resource andAction),it would be too confusing to allow for the cross product of theduplicatecategory types in each list to be specified. Instead I am proposinglistsof exactly the attribute category values from which a virtual request context for each decision is constructed. 3. The prior scheme of echoing back selected attribute values tocorrelaterequests and responses would become too cumbersome and potentially ambiguous. Instead, I am proposing the an arbitrary string label on each decision list (specifically an XML attribute called CorrelationId) beusedfor this purpose. 4. It seems to me that it might be a good idea to retain the Multi- Resource Profile in much the same form as in 2.0 and define a totallynewMulti-Decision Profile using this scheme. Here is roughly how this new style of request would look. <Request> <DecisionLists> <DecisionList CorrelationId="FirstDecision"> <ListReference URI="Sub1"/> <ListReference URI="Env"/> <ListReference URI="Res1"/> <ActionReference URI="Act1"/> </DecisionList> <DecisionList CorrelationId="SecondDecision"> <ListReference URI="Sub1"/> <ListReference URI="Sub2"/> <ListReference URI="Env"/> <ListReference URI="Res2"/> <ListReference URI="Act2"/> </DecisionList> <DecisionList CorrelationId="ThirdDecision"> <ListReference URI="Sub3"/> <ListReference URI="Env"/> <ListReference URI="Res1"/> <ListReference URI="Act2"/> </DecisionList> <DecisionList ... > ... </DecisionList> </DecisionLists> <Attributes Category="Access_Subject" XML:Id="Sub1"> <Attribute> ... </Attribute> <Attribute> ... </Attribute> <Attribute> ... </Attribute> </Attributes> <Attributes Category="Intemediary_Subject" XML:Id="Sub2"> <Attribute> ... </Attribute> <Attribute> ... </Attribute> <Attribute> ... </Attribute> </Attributes> <Attributes Category="Intemediary_Subject" XML:Id="Sub3"> <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"> <Attribute> ... </Attribute> <Attribute> ... </Attribute> <Attribute> ... </Attribute> </Attributes> <Attributes Category="Resource" XML:Id="Res2"> <Attribute> ... </Attribute> <Attribute> ... </Attribute> <Attribute> ... </Attribute> </Attributes> <Attributes Category="Action" XML:Id="Act1"> <Attribute> ... </Attribute> <Attribute> ... </Attribute> <Attribute> ... </Attribute> </Attributes> <Attributes Category="Action" XML:Id="Act2"> <Attribute> ... </Attribute> <Attribute> ... </Attribute> <Attribute> ... </Attribute> </Attributes> ... </Request> Let's discuss this on the call and then I can proceed to define Schemaandtext. 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]