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

["Jan Herrmann" <herrmanj@in.tum.de>]

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 <AttributeValue Id=resource-id /> becomes a
instantiated attribute?
If we agree that option 1 is a no go than option 2 is the last solution to
choose. 



Regards and happy weekend
jan


 


> -----Ursprüngliche Nachricht-----
> Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Gesendet: Freitag, 20. November 2009 14:52
> An: Jan Herrmann
> Cc: XACML TC
> Betreff: RE: [xacml] New issue: new attribute ids for xml multiple
> decisions
> 
> See comments inline.
> 
> > -----Original Message-----
> > From: Jan Herrmann [mailto:herrmanj@in.tum.de]
> > Sent: Friday, November 20, 2009 03:01
> > To: Tyson, Paul H
> > Cc: 'XACML TC'
> > Subject: AW: [xacml] New issue: new attribute ids for xml
> > multiple decisions
> >
> > 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?
> 
> The meaning and use of XACML "resource-id" is not well specified except in
> a few cases.  I'm not sure it is necessary to specify the use of resource-
> id in this case.
> 
> In practice, the only reasonable interpretation of resource-id in this
> context is as a primary identifier for the compound resource represented
> by the XML content.
> 
> >
> > 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 ??
> 
> The individual decision requests would include the original resource-id,
> if present.
> 
> >
> > 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 <Request>). Further we could say
> > that in the derived individual request the resource-id will
> > have a value equal to one of the individual resource (as
> > specified by resource-selector and the scope value). Thus
> > resource-id in the individual decision request will equal to
> > what your proposed authorized-resource-id will do.
> 
> But that would prevent the use of resource-id that I suggested above: as
> an identifier of the resource represented by the XML content.
> 
> For example, I might represent some product structure as an XML document.
> The product structure is an assembly, consisting of sub-assemblies and
> detail parts.  The "resource-id" might be the part number of the top
> assembly.  I want decisions about all the detail parts in the assembly.
> These would be the "authorized-resource-id" values in the individual
> decision requests.  The top "resource-id" might participate in the policy
> evaluation, so it must be available in each individual request context.
> 
> >
> > This solution will fulfil the problem 2 you pointed out (i.e.
> > overloaded resource-id meaning) and in case we exclude the
> > resource-id value in the multiple decision request than issue
> > 1 will also be addressed.
> > The advantage, reuse the existing resource-id attribute
> > instead of introducing a very similar new
> > authorized-resource-id. BTW why did you put authorized in the name?
> 
> I'm not completely satisfied with the attribute name.  We need something
> that means "identifier of the individual resource node about which the
> authorization decision was given".  It is a sort of resource-id, so the
> name should include "resource-id".  But none of the choices convey the
> meaning very well:  "decision-node-resource-id", "individual-resource-id",
> etc.
> 
> >
> >
> > Best regards
> > Jan
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> > > Gesendet: Donnerstag, 19. November 2009 23:10
> > > An: XACML TC
> > > Betreff: [xacml] New issue: new attribute ids for xml multiple
> > > decisions
> > >
> > > 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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