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 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
---------------------------------------------------------------------
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
|