Re: Question on nested/related entity profile

[Steven Legg <steven.legg@viewds.com>]

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
condition.

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

Regards,
Steven

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