Re: [xacml-users] Clarification of Hierarchical Resource Profile

["Rich.Levinson" <rich.levinson@oracle.com>]

Title: Message

Hi Steve,

Not sure if I fully understand your questions, but will try to respond inline. Note:
my first few responses are attempting to understand your question, the later
responses are probably closer to being in the answer space of your questions.

I do not expect that this will fully answer your questions but hopefully it will
move the ball down the field a bit.

    Thanks,
    Rich


Steve Bayliss wrote:

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

Hi

 

I'm seeking to clarify my understanding / the intent of the Hierarchical Resource Profile.  Primarily XACML 2.0, but I understand that 3.0 mainly refines and adds clarity, so anything from 3.0 that's relevant in this respect I am interested in.

 

I'm iinterested in the hierarchical path representations of non-XML nodes, ie 2.0 spec lines 190 et seq.

I am having trouble parsing the following paragraph. I will deal with each segment in sequence:

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

My question is if the Hierarchical Resource Profile deals (is intented to deal with) with resources-in-path-context. 

The sentence above appears to be asking the question:

    Does the HRP deal with "resources-in-path-context"?

If that is the question, then what does the term "resources-in-path-context" mean? For example,
XACML Policy deals with information in the RequestContext. Is this what you are referring to?

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

That is, if a resource belongs to multiple hierarchies/has multiple parents/ancestors, can a policy be written for this resource-in-path-context. 

The answer to the first part of the question is "Yes, a policy can be written for it.".
As above the term "resource-in-path-context" is undefined, at least to me, so I do not understand the last part of the question.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

(to put it another way, policies dealing with resources when being accessed as part of a particular collection having a specific policy, rather than a resource being accessed, and because it is a member of - rather than being accessed in the context of being a member of - having a specific policy).

I do not understand the above statement at all. The first phrase appears to use the term policy redundantly:

"policies (dealing with resources when being accessed as part of a particular collection) having a specific policy"

The remainder I find in more difficult to parse. My point here is not to criticize your sentence structure, but to
try to understand what the point is you are trying to make, and possibly by explaining why I find it confusing,
will help to establish a terminology where the issues can be addressed. That being said, the last phrase appears
to me to be saying:

There is some kind of distinction between:

• a resource being accessed because it is a member of (a specific collection?)
• a resource being accessed in the context of being a member of (a specific collection?)

Is this the point, that the above two bullets are distinct in some manner?

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

Example paths for a resource "c" (ignoring the fact these aren't URIs, I gather this restriction was relaxed in 3.0)

/a/b/c

/x/y/c

Ok, assuming the above URI pathname portions plus leading "/" are provided as resource-ids (where multiple resource-ids
for the same resource are allowed as specified in section 6.3), the two provided above seem like a reasonable pair of example paths.
Note: I do not believe there was intentional "relaxation" in 3.0. Note there are 2 non-XML node identification schemes in the HRP:

• The URI scheme: section 2.2 (of both XACML 2.0 and 3.0)
• The "ancestor scheme": section 3.2 of XACML 2.0, and section 2.3 of XACML 3.0.

If the URI scheme is used the resource-id must be a URI. If the ancestor scheme is used, then that is not a necessary condition.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

According to the spec, a request for resource c should result in two separate resources in the request context, a resource-id with value /a/b/c and a resource-id with value /x/y/z - is that correct?

There is only one resource, but it will have 2 resource-id's, so the answer to above is "no" to the first part and "yes" to the 2nd part.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

And two different policies, one specifying (as URI regex match) /a/b/.* and the other /x/y/.* would both match?

There is no requirement for two Policies, as opposed to say two Rules, but yes, it is likely that both the regex's you
propose would appear.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

Is it also permissible for the incoming request to the PEP to specify the full path, for instance to state that resource c is being accessed in the context of collection b which is a member of collection a?  Thus only the first policy would match?

It is ok to specify only one path in the request, but it depends on the Policy structure whether that would
be accepted or not. i.e. does the Policy state:

• ( /a/b/.* AND /x/y/.* ), or
• ( /a/b/.* OR /x/y/.* )

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

That is, because a full resource-id is already present then the engine shouldn't go away and build the paths.

Sorry, I am not sure what you are trying to say here. There is no requirement on the engine to use any
specific method for processing the above scenario.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

And is it conceivable that both forms could exist together?

I assume so, however, it sounds like you may have a concern that for some reason both forms should not
co-exist. Is that a concern?

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

For instance, if there was a resource attribute of object-ID, and it is defined that resource-id is formed of the full path to object-ID then we could have

 

Request one:

specifies resource object-id = "c"

result: engine builds all applicable paths to "c" - ie two separate resources with their own resource-id (so both above policies match)

I'm afraid you are going to have to be more specific here about what information is being processed.
My assumption is that all required info is in the request context. If all that is there is "c" then how does one
derive full paths?

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

Request two:

specifies resource-in-path-context, specifying resource-id directly as "/a/b/c"

result: engine does not build resource-id and only the first policy matches

Correct, but see comment above. It depends if Policy requires resource to be member
of both hierarchies or only one hierarchy.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

Any guidance on this appreciated.  My reading so far of the specs suggests that the Hierarchical Resource Profile isn't intended for resource-in-path-context (or resource-accessed-as-member-of-collection).

Again, I am not sure what the term "resource-in-path-context" precisely means or the alternate phrase:
"resource-accessed-as-member-of-collection", at least in the context of the HRP. The HRP is intended
to represent single nodes in a hierarchy, and to also consider using the Multiple Resource Profile
for defined "scopes" of nodes within a hierarchy.

001e01cbb7f7$85a884d0$0301010a@asusp4t533" type="cite">

 

Thanks

Steve