OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

  • 1.  New issue: new attribute ids for xml multiple decisions

    Posted 11-19-2009 22:11 
    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


  • 2.  AW: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-20-2009 09:01 
    Hi Paul,

I like your proposal but I am wondering why you are not using the
resource-id attribute directly instead of adding the new
authorized-resource-id attribute. Let me explain:

According to your proposal a multiple decision request and one of derived
decision requests will look like this:

multiple decision request: 
- resource-selector = xpath that selects a set of nodes
- scope = "XPath-expression"
- resource-id = empty? or not present?
What is the value of resource-id in a multiple decision request?

derived individual decision request:
authorized-resource-id = xpath to exactly one node (in the set as specified
by resource-selector and the scope value).
- resource-id ??

It seems to me that we could also say that in a multiple decision request
the value of the resource-id attribute must be empty (or even not present
what seems to be allowed following the schema for


  • 3.  RE: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-20-2009 13:54 
    See comments inline. 

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 4.  AW: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-20-2009 14:51 
    Hi Paul, 
Your described use of the resource-id value in the multiple decision request
appears to be very application specific. In fact you propose to use it as
some sort of metadata describing the multiple resource as a whole. I am not
sure if it makes sense to use the central resource-id attribute for such a
thing. In fact all information you use in your example can be obtained by
the general, generic mechanism too.

E.G.
In the example you gave, you want to put the part number of the top assembly
in resource-id.

In fact all access rules referring to the top assembly as a whole can also
match the derived individual resource-id values that have an value equal to
the element node of the top assembly. Therefore there is no real need for an
additional meta data attribute describing the xml structure en bloc. The
root node of the structure serves for this purpose as well.

Further you mentioned that "The top "resource-id" might participate in the
policy evaluation, so it must be available in each individual request
context." This is true and it is available as the individual request
contexts will have individual resource-id values that point to an descendant
node of the top assembly root node. In case you control access on a part of
a sub-assembly, than you can always go up to any ancestor node of this part
if you need further information to derive the access decision (e.g. select
relatively to the ind. res-id the part number of the top assembly - e.g.
encoded as an XML attribute of this assemply).

Conclusion:
According to your example I don't see the enhanced capabilities through this
standardised meta data attribute for an xml resource. Of course a user can
add it if needed, but it seems to be very application specific thing. Maybe
I miss something here. If so it would be great if you could further detail
were the advantages when using the multiple decision resource-id  show up.
Especially what can't be done through the individual resource-id values and
relative selectors?

The naming aspect:
From my point of view resource-id is the identifier of the resource. In case
of individual decision requests the resource is a single node. As the 
The xpath expression to this node is the identifier of this node. The xacml
attribute holding this xpath expression thus is the resource-id attribute.
Therefore I think resource-id without any extra wording around expresses the
fact pretty well.
In case of a multiple decision request there is a set of resources and thus
three approaches may be possible:
1. leave resource-id empty.
2. do not include this attribute in the multiple decision request
3. the resource-id value must contain the name of all individual resources
in the multiple decision request (directly c.p. 3.a or idirectly c.p.3.b).
Here two sub-solutions are possible:
3.a: list them explicitly (? as  a bag, ?a long string) -> :-(
3.b: in the xml use case the multiple resources are also hierarchical
resources. Thus the root node of the hierarchy can be used as sort of
"representative" of all individual resources.

Evaluation:
option 3.a:
pretty ugly solution
option 3.b:
Possible but xml use case specific (even if we have different sections in
the new versions of the mult. & hier. resource profile it should be the aim
to keep where possible the same concepts in the guidelines for the different
use cases.
Further I don't see the need to have such an "representative" node encoded
as an special xacml attribute. One of the individual resource-id values will
have the same value and further it will be contained in all other individual
resource-id values.
--> I would  not follow option 3.b

option 1: 
Might contradict what you called the "implicit contract that prohibits the
context handler from changing attribute values". I am not sure where this
comes from but I assume that is was discussed earlier. Question: is it a
change if the attribute value was not there and gets inserted afterwards?
i.e. Is it a change if


  • 5.  RE: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-20-2009 16:57 
     

> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  Re: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-20-2009 19:26 
    

  
  


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


  • 7.  Re: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-20-2009 21:10 
    

  


Note: as a general FYI, I am considering revising the proposal to use
actual absolute XPath path expressions as an alternative to Clark
notation. In this scenario, we would need to state a recommended
format, but it may be possible. For example, in the email ref'd in prev
msg:
    
http://lists.oasis-open.org/archives/xacml/200909/msg00099.html

    
instead of having node names like:
    

    /{foo}objects/{foo}book[1]
    

    
we would have an actual XPath expression (I am not sure of the syntax
yet) like:
    

    /objects[namespace-uri()="foo"]/book[1][namespace-uri()="foo"]
    

    
where the namespace would be represented as an actual expression that
could be evaluated by XPath, but because things were fully laid out
could also be examined and processed by regular expressions without
ever having to directly access the xml document.

    
These expressions could also serve as resource-id's for the multiple
decision profile.

    
I will try to firm up the syntax, and if anyone is well-versed or
expert at these xpath expressions, please feel free to offer
suggestions.

    
    Thanks,
    
    Rich


    
Rich.Levinson wrote:

    4B06ED00.4000408@oracle.com" type="cite">
  
  
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


  • 8.  RE: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-23-2009 12:41 
    




    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


  • 9.  Re: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-23-2009 12:16 
    Paul,

I think this is an excellent proposal.

There is one more serious issue with the old/current approach. If a PDP 
does not implement the multiple decision/request profile, the "raw" 
initial request would be processed against the policies without any 
warning, leading to potential security issues. Thus the old way of doing 
it is bad for security as well since it fails unsafely.

Best regards,
Erik




Tyson, Paul H wrote:
> 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


  • 10.  RE: [xacml] New issue: new attribute ids for xml multiple decisions

    Posted 11-30-2009 13:12 
    After further analysis, described in [1], I revise this proposal.

1. Instead of a "resource-selector" attribute, define an additional
generic "content-selector" attribute like:

	urn:oasis:names:tc:xacml:3.0:profile:multiple:content-selector

2. Instead of "authorized-resource-id", use the categorized
"content-selector" attributes proposed in [1].

When any Attributes category contains a "multiple:content-selector"
attribute, it will be expanded into multiple individual Attributes, each
with a "[category]:content-selector" attribute that selects exactly one
node in the Content of that category.  This value will be used to
evaluate the request, and will be included in the response.

Regards,
--Paul

[1] http://lists.oasis-open.org/archives/xacml/200911/msg00072.html



> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


Related Content