[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
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;
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]