OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]