[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
Hi Rich I knew about the RSA Interop but could not find details of the way BTG was actually implemented. I will now look at these docs with our medical colleagues to see if it suffices. But one immediate question comes to mind. Why would the user or the PEP always issue a second request when denied access to a resource? How would they know when to and when not to. And if they did it everytime, and the SAML-XACML protocol is being used to contact a remote PDP, then this is extremely wasteful of resources and time consuming. Since the PDP has the policy rules anyway, it can short circuit this by replying BTG only in the cases when it knows the user does have the second type of permission. regards David 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]