Re: [xacml-users] Question regarding resource hierarchies

[Laird Nelson <ljnelson@gmail.com>]

On Thu, Jun 9, 2011 at 3:49 PM, Gerry Gebel <ggebel@axiomatics.com> wrote:

GG: XACML defines three things: the language for expressing access policies, a reference architecture of the XACML components in an authorization system and the protocol for how PEPs and PDPs communicate with each other (that is, how to make an access request and handle the response)

OK, got that.
 

The application/PEP sends along the attributes it knows about to the PDP which could include the user and the course.

OK, but to use my oversimplified example again: let's say that if you have a course object in a Java program that it does not, for whatever reason, provide a programmatic way to get "back" to its containing department.  The application in this case is going to have to be set up to assemble a hairball Java construct...

...that can be converted to a XACML resource (or maybe hierarchy of such resources)...
...that contains the course (or at least its attributes that are deemed worthy of being evaluated by the PEP)...
...as well as the department (or at least its attributes that are deemed worthy of being evaluated by the PEP).

So my application needs, in part, to define the kinds of resources it's going to make available to the PEP, and that definition is going to--in part--be based off the kinds of policies that the application designer has in mind when he builds it.

That is, suppose the app designer sits in a dark room somewhere and muses, hmm, yes, OK, it is likely that authorization decisions will need to be made about courses based on their department, owners, phase of the moon, and campus.  Suppose that this app designer conveniently forgets to consider (I don't know) adjunct professors, so consequently never provides a way to ship such a construct to the PEP in Resource form.

Meanwhile, some policy author writes a XACML Rule to base an authorization decision off some attribute of the incoming resource--which is a hairball formed out of the course, some of its department attributes, the phase of the moon, some campus details, etc. etc.--that has to do with adjuncts.  Since the application never (indirectly) supplies the PDP with enough information to decide, the PDP will always return some sort of negative response (since adjunct information never rides along.

Or, if I am hearing you right, and I clearly need to read more about this, the PIP can somehow supply the PDP with the missing details.  I can think of several cases where this sort of thing would be impossible in the not-so-fictional architecture I'm working with.  :-)

It sounds like the solution here is to go back to the app designer and say, look, the policy author came up with something you didn't supply.  Oopsie; please recompile support in there for that; thanks.

(Rereading this it sounds snarky; that's not my intent; just trying to walk this through.)

Do I have that about right?
 

Your policy likely will be written based on departments or other affiliations that the PEP/application does not have at its disposal. In this case, the PDP can look up what department the user is in (via policy information point -PIP- interface) and before making its decision. So, the PEP and PDP work together to derive all the necessary attributes to make an access decision

...possibly involving the PIP, which may or 
may not be the application itself, and exists to supplement the incoming
 resource/subject, yes?

Thanks very much for your helpful response.

Best,
Laird