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

[Daniel Engovatov <daniel@streamdynamics.com>]

> In the use case I am considering, for the sake of concreteness, I  
> am assuming that each PC has a record in a table that in order to  
> support its management has at least the following 3 fields:
> PC serial numberL: r*
> DEPT id:  /a1/*
> FACILITIES-id: /a2/*
> Therefore, in the example of this use case from earlier email, my  
> "database" would contain the following records:
>
> PC    DEPT-id     FACILITIES-id
> r1    /a1
> r2                /a2
> r4    /a1/b1      /a2/b2
> r5    /a1/b1/c1   /a2/b2/c2
>

More often you would see a DB schema where each resource is linked to  
the "dept" or "facilities" it belongs to.



> Basically, the DEPT manager has decided to name the resources that  
> are under dept control, r1,r4,r5 using the /a*/b*/c* scheme where  
> the value "1" is used to indicate DEPT names. (Actually, I think  
> all that is necessary is for the root to have a unique name, but  
> let's ignore that for now)
>
> Similarly, the FACILITIES mgr is using the names with the "2"  
> suffix for the resources under facilities control, r2,r4,r5.
>
> My questions for you now are:
> do you agree that it "could" be set up this way? (while recognizing  
> there are other ways as well)
Possibly, but personally I would advise anybody against using such  
naming schemes as it would make it next to impossible to perform any  
reorganization.

> is the issue that we are discussing simply that the naming I have  
> chosen for the DEPT-id and FACILITIES-id is simply an  
> "unnecessarily complex" naming scheme, and that I could have chosen  
> something simpler?

Yes, they are not generic enough and unnecessarily complex.   I do  
not think that we should add anything like that to the standard.     
Existing "ancestors" profile uses opaque identifiers and does not  
introduce any ordering.
> if the above is the case, then what are the simpler schemes for  
> these ids that would represent a "better" approach?
This use case can be trivially mapped into the existing "ancestors"  
approach.   It is simpler, and it is not broken in any way.

Most often, link to "facilities" and "dept" will be stored in the  
"pc" record.   When performing authorization all that is needed is to  
define a shceme that populates "ancestors" attribute in the context.   
It will look like
{"r5", "dept-id", "facilities-id"}.  That is enough to apply policy.   
Nothing else is needed.

There are many way to create hierarchical structures.   If we are to  
publish anything, I think it should be the most generic one that does  
not introduce any additional concepts to the XACML (like naming  
schemes and such).

I strongly advise against inclusion of any naming schemes into the  
"ancestors" hierarchical profile.   WHile the language of that write- 
up can use some improvement, the fundamental approach is sound and  
non-ambiguous.  If TC feels that such an expansion is needed, a  
separate profile should be made for that. I will try to get on the  
call tomorrow to answer any questions.

Daniel;