[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]