Re: [xacml] Break the Glass policies

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

Hi Seth

this is an interesting approach and one I had not considered before. But 
I think it still has some flaws.

Firstly the PEP must operate by never sending this BTG attribute in its 
first request context (otherwise it would be assuming that the user 
always wants to BTG). If the response is grant or deny, end of story, 
but if it is indeterminate it asks the user if she wants to BTG. If the 
user says Yes, then the PEP passes the BTG attribute with the required 
value and gets grant plus obligations.

Now here is the first problem with your method. The user makes a second 
access request for the resource (say medical record) and now either the 
whole process is repeated to the annoyance of the user, and the 
duplication of obligation enforcement, or the intelligent PEP knows the 
user has already BTGed once so does not need to do it again and the PEP 
automatically sets the BTG attribute on the request context, whereupon 
the obligations are returned again. Now should the PEP enforce the 
obligations or ignore them?

Therefore, from the PEP's perspective it is not ideal for the following 
reasons.

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

ii) does a dumb PEP make the call, get indeterminate then make a second 
call, to the repeated annoyance of the user.

If you have a BTG response and a BTG state, then the user only needs to 
BTG once, the state is set and thereafter the accesses are granted with 
no obligations until the state is reset.

regards

David


Seth Proctor wrote:
> 
> FYI, the way I have implemented this in the past is by hitting a point 
> in the policy evaluation where a well-known BTG attribute is required. 
> This can only be supplied by the PEP, so the result is indeterminate and 
> the accompanying detail is that this attribute was missing. This signals 
> the PEP that it should prompt the user for whether or not they want to 
> proceed.
> 
> Personally, I like this style over a new kind of return value, since the 
> first evaluation really isn't resulting in a decision. In other words, 
> the result (to my mind at least) is that the PDP needs to know more 
> before proceeding, which is what Indeterminate means. Hope this helps..
> 
> 
> 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
> 

-- 
-------------------------------------------------------------
The Israeli group Breaking the Silence has just released a collection of
testimonies by Israeli soldiers that took part in the Gaza attack last
December and January. The testimonies expose significant gaps between 
the official stances of the Israeli military and events on the ground.

See  http://www.shovrimshtika.org/news_item_e.asp?id=30

The Israeli government defies Obama, and continues its settlement expansion

Israel plans to allocate $250 million over the next two years for 
settlements

http://www.palestinecampaign.org/index7b.asp?m_id=1&l1_id=4&l2_id=24&Content_ID=698

whilst simultaneously continuing to bulldoze Palestinian homes

http://salsa.democracyinaction.org/o/301/t/9462/campaign.jsp?campaign_KEY=27357

*****************************************************************
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

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