[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
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 multiple >>> >> decisions >> >>> in a single request. It was agreed that a request could specify >>> >> arbitrary >> >>> combinations of attribute categories (with no duplicates), but that the >>> actual attribute values would only be specified once. The scheme would >>> >> not >> >>> require 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 Attributes >>> >> to >> >>> indicate which set of attributes to use. >>> >>> 2. Since all categories could be specified (not just Resource and >>> >> Action), >> >>> it would be too confusing to allow for the cross product of the >>> >> duplicate >> >>> category types in each list to be specified. Instead I am proposing >>> >> lists >> >>> of 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 to >>> >> correlate >> >>> requests 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) be >>> >> used >> >>> for 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 totally >>> >> new >> >>> Multi-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 Schema >>> >> and >> >>> text. >>> >>> 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]