[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
David, If I undesrstand you right, you want PEP to know at the end of first call that access is allowed for BTG scenario. Is it not resolved if PDP sent Permit with an Obligation? 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]