Re: [xacml] Break the Glass policies

[David Chadwick <d.w.chadwick@kent.ac.uk>]

Hi Seth

I think the real disconnect was highlighted by Martin. I am wanting to 
remove as much as possible from the application developers (which to me 
is the PEP) and put as much of the work as possible in the application 
independent code (which currently is the PDP) in order to simplify the 
task for application developers. Your approach however places some 
burden on the PEP developers.

In my latest paper at DIM in Chicago which I presented in November, I 
proposed an application independent PEP (AIPEP) that could do some or 
all of this work on behalf of the PDP. In this way the PEP has nothing 
to do, the PDP remains stateless, and the AIPEP holds the state and does 
other work that is application independent (like calling the PIPs etc).

So if you take the viewpoint, how can I provide BTG functionality for 
all applications so that they have the minimum of extra work to do (ie. 
no state holding or special code of knowledge other than behaving in one 
fixed way for one new response type) then you will probably see where I 
am coming from. I believe that I can see your viewpoint, since you say 
you are an implementor of both PDPs and PEPs, and it requires some 
application specific tweaking in order to get BTG to work efficiently. 
In our work we generally do not provide any PEP code and therefore we 
want to do everything for the application in the application independent 
layer.

However you are correct in saying that a stateful PDP does present its 
own problems when distributed decision making has to take place, which 
means that extraction of state to an outside entity can be beneficial, 
but as my other email points out this also has its own disadvantages.

I would be happy to work on a profile with you.

Concerning your last P.S. this sounds a bit like the DOD operational 
need overriding PDP decision scenario, but its going to be complex to 
determine the value of operational need.

regards

David


Seth Proctor wrote:
> 
> 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..
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************