On Thu, Jun 9, 2011 at 3:49 PM, Gerry Gebel <> 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
