[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
Hi Dilli Dilli Dorai wrote: > David, > If I undesrstand you right, you want PEP to know at the end of first > call that access is allowed for BTG scenario. yes correct, because there are policy rules that say this. > Is it not resolved if PDP sent Permit with an Obligation? No, because as explained in Babak's and Erik's paper, you have to differentiate between a genuine permit with or without obligations, and a special (BTG) Permit with obligations for any user who has the same attributes and is making the same request multiple times. I dont believe you can do this with their paper. In effect there are three classes of user - those who are always permitted - those who are not normally permitted but are in an emergency - those who are always denied It is quite simple to formulate rules for the above using a single condition for the middle case (IF Emergency/BTG is true). Once the glass is broken the condition becomes true and the user always has access until the glass is reset. I dont believe you can do this using obligations regards David > May be the standards can specify a standard obligation-id for BTG. > Thanks. > -Dilli > > Rich.Levinson wrote: >> Hi David, >> >> At the RSA 2008 Interop, we demonstrated an "emergency override" >> capability that I believe is equivalent to BTG, and was even referred >> to as BTG during requirements analysis. We did not require a new >> return code, but simply implemented this as part of the policy >> definitions - basically, a user requested access and was denied, then >> re-requested access with a new Permission (HL7) provided in the >> request, which enabled access. >> >> The details are in section 2.2.4 of the document that may be found on >> the XACML TC main page: >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#expository >> >> The doc is described here: >> http://www.oasis-open.org/committees/document.php?document_id=28030&wg_abbrev=xacml >> >> The zip file containing the doc is in this zip file: >> http://www.oasis-open.org/committees/download.php/28030/XACML-20-RSA-Interop-Documents-V-01.zip >> >> >> Based on that implementation of the capability I would like to >> understand better the need for a "permission to BTG" response. In >> particular, why not just return the "permission" as an Obligation to >> the PEP to notify the user of this option? >> >> Thanks, >> Rich >> >> >> >> David Chadwick wrote: >>> I have just returned from ACSAC in Hawaii where I presented a paper >>> on the BTG-RBAC model. BTG is equivalent to breaking the glass on a >>> firedoor. You are not normally granted access but in an emergency you >>> are if you decide to BTG. This model requires the PDP to return one >>> of three responses to the PEP instead of the traditional two (grant >>> and deny) (forgetting for now indeterminate and not-applicable) >>> >>> The semantics of the new "permission to BTG" response are >>> >>> - this user is not granted access, but will be granted access if >>> he/she decides to break the glass. >>> >>> The application can then display a screen to the user asking if they >>> wish to BTG and warning them that they will be held accountable for >>> their actions if they decide to BTG. At real hospital trails in the >>> main hospital in Porto, Portugal, where my PhD student works, results >>> show that nearly 50% of doctors decided not to BTG when given the >>> opportunity to do so. (The results are presented in our ACSAC paper >>> along with the model). If the user decides to BTG then this grant is >>> accompanied by a set of obligations which can perform audit, email >>> the user's manager, reset the broken glass in 30 minutes etc at the >>> wish of the policy writer. We have implemented a number of these >>> obligations. >>> >>> Whilst a complete implementation requires a truly stateful PDP, we >>> have implemented support for BTG (with some limitations) using Sun's >>> XACML PDP with a stateful wrapper that holds the BTG state in an >>> obligation object. (We will be writing a paper on this sometime in >>> the New Year). Either way, the PEP is given an extra response, >>> "permission to BTG" when it asks if the user can access a particular >>> resource. The reason we have done it this way, rather than getting >>> the PEP to make multiple calls to the PDP and hold the BTG state >>> itself, is simple, it makes it trivial for any application to support >>> BTG policies, which can be simply added to the access control >>> policies of any stateful or stateless PDP (XACML or otherwise). >>> >>> So, after this very long introduction, my question to the group is >>> >>> Can we standardise the BTG response and add it to the XACML standard >>> as a new response in the response context. >>> >>> 1. Ideally I would like to create a fifth enumerated value for >>> decision, called BTG >>> >>> 2. As a sort of hack, we could create a new Major status code called >>> BTG, but this is a hack, status codes are optional and the response >>> is neither grant or deny but is genuinely intermediate to these. It >>> is not indeterminate or not-applicable either, so which decision >>> would accompany this status code? >>> >>> 3. We can always invent our own minor status code and put BTG there >>> without perturbing the XACML standard, but this is effectively the >>> group saying we dont see a requirement for BTG policies. >>> >>> Comments please. >>> >>> regards >>> >>> David >>> >>> >>> ***************************************************************** >>> 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 >>> >>> ***************************************************************** >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> --------------------------------------------------------------------- >> 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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]