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] Issue: Hierarchical profile appears ambiguous and inconsistent


Hi Seth and Daniel,

It appears to me that this discussion is starting to take a trajectory independent of what is currently in the Hierarchical resource profile. This profile, as specified in the abstract and throughout discusses the procedures for dealing with resources that are structured as hierarchies and are represented by one of two types of "nodes in a hierarchy".
  • In one type the resources are represented as "nodes in XML documents".
  • In the other type, the resources are represented "in some non-XML way".
If that was the end of the spec, then maybe I would agree with your opinions on how "generic" you are suggesting the non-XML way should be. However, when you get past the front cover, you quickly come on section 2.2 which states the following:
  • The identity of a node in a hierarchical resource that is not represented as an XML document instance SHALL be represented as a URI that conforms to [RFC2396]. Such URIs are of the following form.
    <scheme> “:” <authority> “/” <pathname>
In case one thinks that is not specific enough wrt to how it relates to hierarchy, section 2.2 goes on to state:
  • The <pathname> portion of the URI SHALL be of the form
    <root name> [ “/” <node name> ]*
    The sequence of <root name> and <node name> values SHALL correspond to the individual hierarchical component names of ancestors of the represented node along the path from a <root> node to the represented node.
Finally, section 4, that describes how to state policies that apply to nodes says in section 4.1:
  • The representations of the identities of these parents, ancestors, or self will not necessarily indicate the path from the root of the hierarchy to the respective parent, ancestor, or self unless the representation recommended in Section 3.2(should say 2.2): Nodes in a resource that is not an XML document is used.
and for the specifically non-XML resource case in section 4.3:
  • For hierarchical resources that are not represented as XML document instances, and where the URI representation of nodes specified in Section 2 of this Profile is used, the following functions described in the XACML 2.0 Specification [XACML] MAY be used to state policies that apply to one or more nodes in that resource. urn:oasis:names:tc:xacml:1.0:function:anyURI-equal
    urn:oasis:names:tc:xacml:1.0:function:regexp-uri-match
      (should be ...2.0:function:anyURI-regexp-match)
My whole purpose in pursuing this thread has been to correct what I perceive as a flaw in the spec which to a large degree is the result of not showing in section 3.2 how URIs can be used as an alternative to the specific algorithms bulleted in section 3.2.
With URIs you do not need the algorithms because the URIs representing the normative identities of the requested node already contain:
  • "each normative representation of the requested node"
  • "each immediate parent of the node specified"
  • "each ancestor of the node specified"
Nothing else is needed. Note however, that doing the analysis with URIs points out what might be considered to be a flaw in the bulleted algorithms. The bulleted algorithms require obtaining all parents of the requested node's parent on up the line, regardless of whether those additional parents are connected to the requested node by an explicit hierarchical relationship or not.

i.e. the bulleted scheme implicitly forces the requested node to collect ancestors that have not been structurally assigned any direct relationship to the requested node. When hierarchies are used to represent lines of authority, these additional relationships are not relevant and obscure the real lines of authority which are generally what is of interest in enterprise security.

With the URI scheme it would be simple enough to collect these extraneous ancestors if they were desired for some reason, by simply using the bulleted algorithms as is, and using URIs found in ancestors that are not on the requested node's direct path.

However, it is my opinion, that the primary purpose of these specifications is to inform consumers of these specifications on the capabilities contained within the spec so that they may then apply those capabilities to meet their needs.

By only including the bulleted ancestor algorithms in section 3.2, the capabilities of URI, which are clearly specified in the rest of the spec, and were included in the example document in the XACML archive (see section 4.2, 4.3 of http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf), we are effectively making the URI capability so obscure in the spec as to be unusable.

The inclusion of the URI in the spec was an essential part of its creation, although there was not universal agreement as to whether it should be included, as described in this email:
http://lists.oasis-open.org/archives/xacml/200405/msg00104.html

The fact is that URI was included and it remains there, and from my perspective represents an extremely significant ease of use capability. The purpose of my next round of planned changes is to bring the URI out of the darkness so that a reader of section 3.2 will be aware of its availability. This also fills the hole between the URI descriptions in sections 2.2 and 4.3 as URI relates to nonXML resources.

Again, my proposed changes do not change any functionality, they simply explain the capabilities that are currently there, which because of the obscure representation of the existing functionality in the current spec are nearly impossible to understand.

    Thanks,
    Rich


Seth Proctor wrote:
499C53A6.9050409@sun.com" type="cite">
There are many way to create hierarchical structures.   If we are to publish anything, I think it should be the most generic one that does not introduce any additional concepts to the XACML (like naming schemes and such).

I agree with Daniel on this point. One of the strengths of the XACML core (in my opinion) is that it deals with a policy processing model, not the specifics of how XACML systems interact with the world around them.

The idea of generic hierarchies is that a PEP should be able to name a root, and that should result in a PDP processing multiple requests. How that mapping happens is up to some entity outside the scope of XACML. It seems to me like what we're really talking about in this thread is a profile for specific mechanisms or more detailed examples of actual implementation possibilities. I think this kind of clarity is great to have, but should be in a separate place from the abstract discussion of hierarchies (which I think is also Daniel's point). I also think Erik's suggestion makes sense: we should continue to look at these details, but move the core docs forward separately.


seth

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