OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

[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/
> 

break-glass-sequ.png



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]