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: Question on nested/related entity profile

Hi Rich,

On 14/02/2014 8:06 PM, rich levinson wrote:
Hi Steven,

I have finally been able to allocate a little time to review your
"Related and Nested Entities Profile" proposal, and it looks to
me like a really well designed piece of work, with a rich set
of capabilities, that open up some really interesting possibilities
for policy design, such as the examples given in section 5.

Actually, my interest was triggered by the emails that suggested
relating it to the hierarchical profile, and I think I can see the
motivation behind that was possibly the nested entities could
presumably be used to construct a resource hierarchy that
could be used as input to a request, possibly enabling the
pdp to produce a "combined decision" by iterating thru
entities in the resource hierarchy and applying expressions
to each resource, while using ForAny or ForAll as a means
of producing the combined decision.

Provided the access control policy can be expressed in a single

But that's not what my question is about at this moment.

My question is about the comparison between the use
of nested and related entities in section 3.1, Fig 1, and
section 5.2, Fig 6.

As I was reading the spec, I was wondering if nested and
related entities were effectively equivalent, and whether
in some sense it was simply a choice of which technique
to use.

There is an equivalence, which is straightforward when the entities
form trees rooted on the access subject and/or resource, but gets hairy
for nested entities when the entities are related in more general ways.

Nested entities can only physically be arranged in a tree. A more
general graph of entities can be mapped onto a tree, but only by
introducing duplicates of the entities that can be reached by multiple
paths. If the graph contains cycles, then the tree is theoretically
infinite. That would be a problem for a context handler that tries to
completely populate the request context. However, a context handler that
expands the request context one entity at a time, on demand, will be okay
because an XACML expression can only take a finite number of steps from
one entity to another entity.

One can't go wrong choosing to use only related entities. Nested entities
may seem a better choice for data that is already tree-structured and doesn't
have natural identifiers for the parts, but it doesn't much matter if they
are related entities instead.

So, looking at these 2 figures, I noticed that in Fig 1, there
is 2 levels of nesting (just my luck that neither of these figs
have line numbering ':)' ):

  * Attribute/AttributeValue is data-type:entity level 1
  * Attribute/AttributeValue/Attribute@AttributeId="...organization"/AttributeValue
      is data-type:entity level 2

So, in Fig 1, the organization entity, Acme Inc., is a "nested entity",
nested 2 levels down in an Attribute/@AttributeId="...relationship",
which could appear in a "stand-alone entity" such as category:access-subject.

And, in fact, in fig 6. this is exactly what is done.

However, fig 6 has an interesting difference from fig 1, which is
that in fig 6, the organization entity, Acme Inc., is now a "related entity",
which was facilitated by having the organization Attribute contain
an Attribute with data-type:...anyURI instead of data-type:entity, as
was done in fig 1.

So, my question is, for example, could we now equally as well in fig 6,
push the two attribute:relationship nested entities out as related
entities using the same technique, by changing the data-type from
entity to anyURI and providing a dummy URI?

Yes we could. I chose to have both nested and related entities in this
example to demonstrate that it was both possible and reasonable to have
such a mix.

Would this have any impact on the Policy?

Yes, though it is minor. The expression in Figure 7 begins like so:

[01] <ForAny VariableId="relationship" xmlns="&xacml;3.0:core:schema:wd-17">
[02]   <AttributeDesignator
[03]     Category="&xacml;1.0:subject-category:access-subject"
[04]     AttributeId="urn:example:xacml:attribute:relationship"
[05]     DataType="&xacml;3.0:data-type:entity"
[06]     MustBePresent="false"/>

Here the "relationship" quantified variable is bound to the nested
relationship entities. If related entities were used instead, then the
expression in Figure 7 would begin like this (only line [05] has changed):

[01] <ForAny VariableId="relationship" xmlns="&xacml;3.0:core:schema:wd-17">
[02]   <AttributeDesignator
[03]     Category="&xacml;1.0:subject-category:access-subject"
[04]     AttributeId="urn:example:xacml:attribute:relationship"
[05]     DataType="http://www.w3.org/2001/XMLSchema#anyURI";
[06]     MustBePresent="false"/>

Now the "relationship" quantified variable is bound to the URIs of the
related relationship entities. The "relationship" variable is only used as
the first argument to the attribute-designator function, which is defined
to take either an entity or a URI reference to one, so the change in
data-type of the "relationship" variable doesn't force any further
changes to the expression. Had the "relationship" variable been used as
an argument to other functions (unlikely), then further changes would have
been required.

One other question, along similar lines:

    By contrast, could we similarly collapse the Request element
    into a single set of nested entities, where the Request element
    could be replaced by a single Attribute element, which would
    contain an AttributeValue of data-type: entity, where the entity
    would contain one Attribute each for Subject, Resource, Action, etc.,
    each of which would contain their own AttributeValue of
    data-type:entity that would contain the collection of Attributes,
    for each of the current top level Attributes collections.

That would be feasible, but would lead to more verbose policies. The
predefined category URIs provide a short cut to the primary entities of
interest to the authorization decision.


At this point I am not suggesting we do anything, but I am simply
trying to understand the capabilities that appear to me to be
inherent in the spec in its current form.


Thanks, Rich

Oracle <http://www.oracle.com>
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017 <tel:+1%20978%205055017>
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

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