OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] New issue: new attribute ids for xml multiple decisions


Rich, I was just addressing 2.2, but looked at the wrong section to get the line numbers.  Thanks for pointing this out.
 
2.1 needs a similar adjustment, but since it covers xml and non-xml resources, we will need to analyze it further.
 
I believe one cause of the problem is ambiguous use of the "resource-id" attribute.  This might need to be addressed as an issue by itself.
 
--Paul


From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Friday, November 20, 2009 13:25
To: Tyson, Paul H
Cc: XACML TC
Subject: Re: [xacml] New issue: new attribute ids for xml multiple decisions

Hi Paul,

I have interest in this issue, but first need a clarification. Your problem statement begins by saying:
"The cd-1 Multiple profile, lines 109-111, specifies that the resource-idattribute in a multiple decision request shall be replaced with a(possibly) different value when creating individual requests. "
The clarification I need is that lines 109-111 in both the pdf and doc files are part of section 2.1.3, which is part of the section 2.1  "Nodes Identified by Scope". However, the rest of the issue appears to focus on section 2.2  "Nodes Identified by XPath". Is this intended? Both sections 2.1.3 and 2.2.3 are similar but not exact, so I'd like to make sure.

Also, this whole mechanism of generating individual requests raises an issue, not unlike the whole URI discussion we have been having on issue 11, in the sense that there needs to be a node identifier (resource-id) generated for each of the individual requests. In principle, this resource-id theoretically could be anything, but if the resource-id is used by the policies as a meaningful identifier of the actual resource that is being evaluated, then there is a real question of what "should" the names of the individual nodes for which access is being requested be called. Even in the XPath case as resource-id, one must come up with an XPath that evaluates to a single node.

As an aside for reference, the general mechanism I have proposed for the extended URI for section 2.2.1 in the hierarchical profile, provides exactly this capability of automatically naming any node in an XML document, with a path to its exact location in the XPath Data Model hierarchy, as well as the document itself.

The proposal doc is attached to this email:
http://lists.oasis-open.org/archives/xacml/200910/msg00030.html

A detailed explanation of how the node names are constructed is in this email:
http://lists.oasis-open.org/archives/xacml/200909/msg00099.html
Note: I am aware of some of the concerns w the URI proposal, however, I believe it fills a gap, which for whatever reason, has been left unaddressed by XPath which is defining an unambiguous identity for each node in the XPath Data Model. In the particular use case of xacml, where the nodes in the xml hierarchy are regarded as resources, the issue arises, as it does in the multiple request profile, of how to "identify" the resources, which is exactly what XPath does not explicitly provide. The proposed solution is an attempt to make explicit this identifier by establishing an unambiguous representation of the node in the XPath Data Model hierarchy, as a URI by resolving the namespace of the prefixes, and simply then listing the natural hierarchical path.

    Thanks,
    Rich


Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF0960408668A@txamashur004.ent.textron.com type="cite">
The cd-1 Multiple profile, lines 109-111, specifies that the resource-id
attribute in a multiple decision request shall be replaced with a
(possibly) different value when creating individual requests.  The new
value is the one that would be returned (if IncludeInResult=true) in the
result.

There are a couple of problems with this.  First, it breaks an implicit
contract that prohibits the context handler from changing attribute
values (it can provide more values, but should never change or remove
values from the original request context).  Second, it overloads
resource-id with a new meaning that is different from its initial
purpose as a primary identifier of a resource.  When used in a multiple
decision request for XML content, resource-id now means something like
"resource selector" in the Request, but reverts to its former meaning as
"primary identifier" in the Response.

I propose that the resource-id attribute should only be used as a
persistent primary identifier for a singleton resource, and that two new
attributes be defined: one for requesting decisions on multiple nodes of
XML content, and another for identifying those nodes in a XACML
response.  The proposed AttributeIds are:

urn:oasis:names:tc:xacml:3.0:profile:multiple:xml:resource-selector
urn:oasis:names:tc:xacml:3.0:profile:multiple:xml:authorized-resource-id

Sections 2.2.2 and 2.2.3 of the Multiple profile should be rewritten as
follows:

=====================
2.2.2 Original request context

The original XACML request context <Attributes> element in the resource
category SHALL contain a <Content> element and an attribute with and
AttributeId of
"urn:oasis:names:tc:xacml:3.0:profile:multiple:resource-selector" and a
DataType of "urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression",
such that the <AttributeValue> of the "resource-selector" attribute is
an XPath expression that evaluates to a nodeset that represents multiple
nodes in the resource category <Content> element. The <Attributes>
element with the resource category SHALL contain a "scope" attribute
with a value of "XPath-expression".

2.2.3 Semantics

Such a request context SHALL be interpreted as a request for
authorization decisions on multiple nodes in the nodeset represented by
the <AttributeValue> of the "resource-selector" attribute. Each such
node SHALL represent an Individual Resource.

Each Individual Decision Request SHALL be identical to the original
request context with two exceptions: the "scope" attribute SHALL NOT be
present and an additional attribute with AttributeId of
"urn:oasis:names:tc:xacml:3.0:profile:multiple:authorized-resource-id"
SHALL be present.  The DataType of this attribute shall be
"urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression", and the value
SHALL be an XPath expression that evaluates to a single node in the
<Content> element. The IncludeInResult XML attribute SHALL be "true".
The content XML node selected by this Attribute SHALL be the Individual
Resource. If the "resource-selector" attribute in the original request
context contained an Issuer, the "authorized-resource-id" attribute in
the Individual Resource Request SHALL contain the same Issuer.
==============================

See these emails for previous comments on this issue:

http://lists.oasis-open.org/archives/xacml/200910/msg00036.html
http://lists.oasis-open.org/archives/xacml/200910/msg00052.html
http://lists.oasis-open.org/archives/xacml/200911/msg00025.html

Regards,
--Paul

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