RE: [xacml] Break the Glass policies

["Smith, Martin" <Martin.Smith@DHS.GOV>]

Seems to me the general (and typical) case is that a policy may call for
more info than is provided by the initial set of user attributes. Maybe
this is info to be supplied:

by the user (a user-provided BTG certification or other self-assertion
-- where the only "attribute authority" is the user him/her-self); or
By a third party (like a supervisor or adjudicator  -- this is a
solution that has been recommended to deal with some homeland-security
situations); or
In the general environment (like a call to a Web service that provide
the current terrorism threat level, or maybe just the time.) 

Furthermore, I a really hoping that the PDP can determine the attributes
of the target in a general-purpose way. That is, a policy should be able
to be something like "if the user is a doctor and the resource is
subject to HPPA (a patient medical record), then . . "  How will the PDP
know that the resource is "subject to HPPA"? Presumably by examining the
query or the actual query results before making an access decision. (I
am not looking for AI here--just assuming that the resources are marked
up somehow with "access-relevant" attributes.)

So, the PDP has to be able to GATHER data from multiple sources to
acquire the variables required by the policies it is applying.   

Martin
 

-----Original Message-----
From: Seth.Proctor@Sun.COM [mailto:Seth.Proctor@Sun.COM] 
Sent: Tuesday, December 15, 2009 9:24 PM
To: David Chadwick
Cc: xacml
Subject: Re: [xacml] Break the Glass policies


Hi David. You raise some interesting points, but respectfully I have to
disagree with you.

> Firstly the PEP must operate by never sending this BTG attribute in 
> its first request context

I have built *many* systems where the user knows that they are supplying
an attribute in the initial request to "break the glass." This can
happen for many reasons, through the usual use-cases have to do with
emergency medical access or other "first-responder" systems. I don't
think this is required, but it's definitely a common scenario that I've
come across in practice in many systems.

> [...]
> i) does a clever PEP anticipate that the attribute is needed and 
> therefore provide it, so that two calls are not needed?

This is entirely application-specific, as is everything else that you
raise. It is *impossible* to know if a give application will want to
query the user to ask if it's ok to "break the glass" with each request,
if it wants to implement SSO, or if it wants to implement this silently.

This is a fact. It has nothing to do with the given system. No matter
what is supported directly in XACML, each system will have its own
requirements, and I can say this confidently based on many years of
working with teams who are trying to support exactly these kinds of
use-cases.

It doesn't matter if there's some special BTG return or an
Indeterminate, it's the same scenario. In both cases, the PDP says that
it can't make a decision and provides detail about what it's missing to
make that decision. The PEP is left to interpret this and decide what to
do. It can be the current Indeterminate response or some new kind of
response, but that will have *no* effect on the PEP, which will still be
application-specific and have to decide how it responds to the PDP's
decision.

In other words, any issues of how "smart" or "dumb" or "stateful" a PEP
is doesn't come into play here. There is simply no difference between
returning a special return type and retuning Indeterminate for a known
attribute, except that the later is already part of the standard and can
be modeled in the current XACML policy format.

The only issue here is whether there is some *standard* behavior for a
resposnse from the PDP which specifies that we're in a BTG scenario and
more detail is required. This has nothing to do with the response format
itself, but could be defined by a profile that defines well-known
attributes and well-known behavior based on those attributes.


seth

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php