Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

[Daniel Engovatov <daniel@streamdynamics.com>]

On Feb 20, 2009, at 8:15 AM, Rich.Levinson wrote:

> Hi Erik,
>
> The problem presented by the commenter is analagous to:
>
>     State/City01/MainStreet
>     State/City02/MainStreet
>
> Just because two separate cities have a street named MainStreet  
> does not mean these are the same street. These are two distinct  
> normative identifiers for two distinct resources.
>

Yes, those are too distinct identifiers, and XACML does not need to  
know anything about its internal structure.    You could identify  
streets by there geographical coordinates, cities by zip codes and  
states by the last name of its governor.  It will work the same.   No  
naming schemes are needed in any form or shape.

You also want to be able to inherit the policy for a "street" from  
county.  County may be represented as "State/County" and city will  
not be on the path.  All you need to supply to PDP is an unordered  
bag containing
{"State/City01/MainStreet", "State/County1", "State/City01"}  If you  
decide to change county identifier to "Nevada County, CA", you do not  
need to change any naming schemes.   You will just need to update  
rules that target county and its descendants.   PDP should not care  
what do you use for identifying policy targets.

This approach introduces the absolute minimum (none) of new concepts  
that PDP need to understand.   You do not need to maintain and  
process any naming schemes.   It covers all possible structures for  
the purpose of policy inheritance.  It does not need to cover  
anything else.

The root of this whole discussion is that we have tried to use one  
document to describe two different solutions.  Proper course would be  
to split it, and leave one for XML documents/URI and one for  
"ancestors" approach.

P.S. On the side note, when we designed a protection scheme for XML  
data structures for what is now known as Oracle Data Service  
Integrator, we found it next to useless trying to rely on XML data  
structure for the purpose of policy inheritance.   We chose to bind  
schema elements directly to protected resources that followed their  
own separate and more generic hierarchy.   That allows a reuse of  
policies independent of transformation and re-factoring of the XML.    
That is similar to the issue of maintaining any hierarchical naming  
schemes for enterprise resources - you do want to decouple them from  
access policy rules.

Daniel;