[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] Scenarios for XACML policies
Hi, thank you for the hint! Although I was looking for the requirements to the policies (e.g., a "regular policy" without any BTG features), this discussion is very interesting to me. Although I did not (jet) read all mails regarding BTG, I have some comments - some of the issues discussed sound familiar to me, and as far as I've read, the solution we presented in [1] has not been discussed. I do not know if it would be an appropriate approach for oasis, but it could be worth having a look at it. We had discussions about similar approaches, introducing additional access control decision or status codes. For us, it turned out that the only reason for an further element is to distinguish a "regular" permit from an "emergency" permit, as an emergency permit should never "overwrite" a regular permit. Suppose a physician, inheriting all permissions from a nurse. To the physician, regular permissions are granted, to the nurse emergency permissions are granted. As the physician inherits all permission from the nurse, the system has to be able to "prefer" (distinguish) the regular permission over the emergency permission. A further access control decision would allow the system to make such a distinction. But, thinking this consequently to the end, we detected that different kinds of "emergency permissions" may require different obligations, e.g., requiring the permission from a supervisor vs. triggering an audit from a local commissary up to raising an alarm to a federal privacy commission. Obviously, similar to the physician/nurse example, one would like to have the least or weakest obligation to be applied. Thus, if there is regular access possible, do not use BTG; if the verification of a supervisor is sufficient for the specific request, do not send an alarm to a federal commission. Thus, in our approach, we separate different "levels" of emergencies and their required obligations into "emergency policies", which extend the permissions of the regular policy (or, as defined in [1], the regular policy refines the emergency policies): only if no regular permission is found, emergency permissions are checked. Requiring the confirmation of the user for applying emergency permissions is just one of those obligations. An "emergency policy combining algorithm" (which is, basically, a regular permit-overrides combining algorithm), iterates starting from the regular policy and the smallest emergency policy to the highest emergency policy. Thus, with this construction, -) the "least possible" emergency permission is chosen automatically (or a regular permission, if granted for the specific request). -) emergency permissions can be structured in levels, which can, for example, have assigned different obligations, conditions, or be activated or deactivated. -) we do not need to introduce any new element (e.g., status code) to xacml and are compatible to (at least) xacml 2.0. When following a simple convention how to structure the "top level" policies (or policy sets), we do not even required to introduce a further policy combining algorithm, as for the emergency policy combining algorithm we can use permit-overrides. -) emergency policies per construction extend the regular policy (and lower emergency policies) as once granted permissions cannot be revoked or overwritten by higher emergency policies. -) there is only one request/response needed between PEP/PDP (see sequence diagram attached). Regarding "state" we have two comments. For the state of the (client) application (e.g., has the user already broken the glass) we think that the state which heavily depends on the state of the client should be "managed" by the client. For example, if there is a "transaction" which requires several permissions and, possibly, several BTG accesses, it is up to the client, to remember if the user has chosen to break the glass (up to a specific level). Other constructions require that, first, the PDP has to hold some state which should be avoided as far as possible, and, second, the PDP has to have some knowledge about the client application, which should be avoided too (as it, e.g., creates redundant information and will lead to inconsistence). Regarding the state of activated or deactivated emergency policies (or already broken glass affecting other users), we see this as part of the policy, similar to known users, role assignments, known and permitted relationships (such as in health care scenarios, e.g., [2]), etc, and should be managed by the PAP. This state may only be altered through a administrator interface. Thus, conceptually, there is some state contained in the PAP which can be retrieved at runtime via the PIP (as it may change more frequent than the "pure" xacml policies). Practically, the state may be saved in the PIP and protected by policies in the PDP. For example, the use case of David Chadwick where, once the "glass is broken", the whole system should switch to "emergency state" (i.e., grant extended permissions), would be implemented as activating an emergency policy and setting the according state in the PAP (if, e.g., only a set of users should have emergency permissions). If you think that my comments are valuable to the discussion, I would be very thankful if you could post it on the mailing list! King regards, Helmut Petritsch [1] Achim D. Brucker and Helmut Petritsch, Extending Access Control Models with Break-glass in ACM Symposium on Access Control Models and Technologies, SACMAT, pages 197-206, ACM Press, 2009. doi: 10.1145/1542207.1542239 [2] M. Y. Becker. A formal security policy for an NHS electronic health record service. Technical Report UCAM-CL-TR-628, University of Cambridge, 2005. On 05/16/2011 04:02 PM, Ludwig Seitz wrote: > On mån, 2011-05-16 at 15:39 +0200, Helmut Petritsch wrote: >> Hi, >> >> I'm currently working on some scenarios describing policies in, e.g., >> health care applications. The overall goal is to provide some analysis >> and audit techniques for, e.g., analyzing Break-Glass accesses, based on >> XACML. >> > There has been a spirited discussion on Break-Glass access on the TC > mailinglist. You should be able to find it in the archives [1] > Search for "BTG". > > Regards, > > Ludwig Seitz > > [1] http://lists.oasis-open.org/archives/xacml/ >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]