Re: [xacml] Break the Glass policies

[Seth Proctor <Seth.Proctor@Sun.COM>]

Hi David. I'm not sure where the disconnect is here, but let me try one 
more time..

> The real difference is that the BTG response requires a stateful PDP in 
> order to work correctly, because once the glass is broken the PDP will 
> return grants instead of BTG responses. Thus the PEP can be dumb but a 
> high quality of service can be given to the user.

I would argue this is no different than any other SSO scenario. Once a 
certain process has happened, you can resolve attribute values and make 
decisions that were unavailable before. You could build a custom PDP to 
do this, but I would tend to use the existing standards to push this to 
the PEP or PIPs.

> In your approach the indeterminate response works with a stateless PDP, 
> which is why the state has to kept by the PEP if a high quality service 
> is to be given to the user.
 >
> So, if the PDP remains stateless the format of the actual return is not 
> that important as the behaviour will be the same in both cases. But if 
> the PDP becomes stateful then the BTG response has clear advantages over 
> indeterminate (but at a cost of complexity in implementing the PDP).

I don't understand why you're getting caught up in the notion of 
staefulness here. There are many scenarios today where XACML is used by 
applications that change state based on the context or past interaction, 
and it doesn't require changing the PDP behavior. If all you want is to 
put state into the PDP (breaking the standard) then I would argue that 
you don't even need a new response format.

> [...]
> What you are doing here is putting an extra burden on the user (who is 
> probably already stressed in an emergency situation) by requiring them 
> to behave differently by providing an extra attribute in the emergency 
> situation that they dont normally need to provide in a normal situation. 

No. Let me be clear: that is absolutely not true. I have said absolutely 
nothing about the user in this situation. Yes, sometimes you want to 
prompt the user, and other times you want the system to take action. All 
I have described is how the PDP and PEP interact. In your original email 
you described a 2-pass protocol where the PDP returned a special message 
to the PEP which then sent a new request, and this is *all* that I also 
have suggested. It's completely up to an application/system to decide if 
the user needs to be prompted before continuing.

>> 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. 
> 
> You see this is the burden that your mechanism requires, which is 
> removed once you have a stateful BTG PDP.

Again, you're confused about the roles here. I'm very clear to say that 
it's the application's option to decide how the user interacts with the 
system. When I have built exactly the systems you are describing I have 
often done it for uses where the user should not be queried, and where 
the PEP know what to do in these cases. There is state, and it's easy to 
implement, but it doesn't require changing anything about the XACML 
processing model.

>> It doesn't matter if there's some special BTG return or an 
>> Indeterminate, it's the same scenario.
> 
> Same scenario but different semantics attached to the return code.

This is exactly my point. You and I are suggesting exactly the same 
thing: there should be some return from the PDP that the PEP recognizes. 
This return should result in future operations being permitted. All I'm 
saying is that this is pretty easy to do today with the existing system. 
I'll also repeat my suggestion that a profile describing specific 
attributes and state models for supporting this in practice would be a 
great contribution.

>> 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.
> 
> No the above is the semantic of your response and of your response only.
> 
> The semantic of the BTG response is quite different. The semantic is 
> more definite as the PDP has made a decision and it means "this user 
> will be granted access if (s)he decides to first break the glass and 
> take the consequences".

Ah. Now that's different than what you said in your first email. This is 
not a different kind of response, but a PERMIT with Obligations. To 
support what you say above only requires a single message, and can 
easily be done today. Personally I don't like this model, because I 
think Obligations are things that you should make a "best effort" to 
discharge, but this gets back to a long history of what Obligations are 
and how you deal with them :)

>> The PEP is left to interpret this and decide what to do.
> 
> that is correct in both cases. But the interpretation is different in 
> both cases even if the PEPs actions are similar in both cases. However, 
> with a BTG response (supplemented with standard obligations) the PEP can 
> do much more tailored and sophisticated actions (unless you also allow 
> obligations to be returned with indeterminate).
> 
> Furthermore, on the second and subsequent calls if the PEP behaves the 
> same each time, the effect is different in the BTG case. In the 
> indeterminate response case, the same sequence of actions will be 
> repeated each time, but in the BTG case the second and subsequent 
> responses will be Grant (up until the broken glass is repaired).

Umm, no, in what I was proposing the second and subsequent responses are 
all permitted because the PEP understands that this is a BTG scenario 
and continues to provide the attribute(s) needed to trigger that logic path.

>> 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.
> 
> I assert that the BTG response with a stateful PDP will have a 
> significant effect on the code that needs to be written for the PEP - it 
> will be much simpler and will also give a better quality of service to 
> the end user.

Speaking as an implementor of both PDPs and PEPs, I'm not sure I agree 
with you here. Among other things, I've built many systems where there 
is a cluster of PDPs that can hit, each of which will provide the same 
response. I've also needed fail-over or quick-restart PDP services. In 
your "stateful PDP" these couldn't be supported. This is just part of 
why the XACML standard explicitly forbids side-effects. If you make the 
"state change" at the PIP that is providing the BTG state value, or in 
the PEP supporting the user, you're ok.

Note that the PEP can remain stateless, and pass back the initial result 
to the application. This doesn't mean the *user* will be prompted, only 
that the application is asked what to do. Now, you can put the state in 
the application, and it can know to provide the BTG go-ahead in each 
future request without having to change anything else in the system. 
This is something I've done in practice for hospital systems as well as 
financial apps, and it works quite well.

I hope this helps clarify a little more what I'm talking about. To be 
clear, I agree completely that BTG-type scenarios are extremely useful, 
I just think that it's easy to implement them a number of ways in the 
existing XACML specification today. I would be very interested to see 
profiles/papers written to capture best-practices and standard 
attributes here. In fact, David, if you'd like to work on something like 
this with me, please let me know!


seth


ps  I hesitate to add this, but I've also done BTG-type scenarios using 
a totally different design approach. Styled in more of a 
trust-management system, I've used policies that are by their nature 
flexible, and generally designed to permit with different levels of 
Obligations. There is no explicit notion of "breaking the glass" there 
is only the system's attempt to decide the context and appropriateness 
of the request and how to balance this against the risk of permitting 
the action. This has the nice property that no state is needed and the 
users are never interrupted. This would take a long time to explain, but 
I thought I'd throw it out there as another example of how the current 
spec can be used for these scenarios..