[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
Martin, David, All I have not understood all the specifics in this discussion, but I think the discussion touches an issue which is currently very underdeveloped/lacking in XACML. I mentioned this at the recent F2F, in the session about future directions for XACML, and I am referring to stateful policies. As you say, for many reasons it is preferable that access control policy is externalized from applications, rather than having to be coded into applications. Currently the XACML PDP is stateless, for many good reasons, meaning that any kind of stateful policy, such as dynamic separation of duties must be handled with attributes. And a policy language for defining the dynamic stateful policies in terms of attributes is also lacking. So this means application code. An example of a dynamic stateful policy would be for instance the well known Chinese wall policy: "If someone accessed information about client A, they must not be allowed to work with any competitor of A". In this case future access rights depend on past actions. Sure, it can all be done with a mix of XACML, application code and attributes, but, as Martin says, it's not ideal since it's not really done through policy external from applications. What XACML will need, once we get 3.0 done so we can focus on the long term future, is an extended architecture which includes a component which maintains state and a policy language for defining that state and how it relates to access control enforcement. I think the PDP should still be stateless, so we don't get state spread out all over the place, but with the stateful component (of some unknown kind, but well defined) which exposes itself as attributes, this kind of dynamic policies could be specified externally from the application. Best regards, Erik On 12/17/2009 07:07 PM, Smith, Martin wrote: > David -- I have not delved in obligations, so I can't make any > meaningful comment. The list of exceptional circumstances are certainly > derived from policy, and it would be far better (less expensive, more > reliable) if they could be maintained there (in PDP) rather than having > to be coded (and updated) in every application. No idea how this would > be implemented, I'm afraid . . . > > Martin > > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Wednesday, December 16, 2009 5:54 PM > To: Smith, Martin > Cc: Ludwig Seitz; xacml; Waterman, K. Krasnow<CTR>; Hammar, Patricia > <CTR>; John, Anil; Tom Karygiannis > Subject: Re: [xacml] Break the Glass policies > > Hi Martin > > Smith, Martin wrote: > >> David -- Agree with your considerations. FWIW, I was visualizing this >> from the ujser interaction POV (w/o worrying about implementation or >> efficiency.) What I imagined was a person issuing a query, and then >> getting a pop-up >> > Yes this is what our hospital application does. BTW we have a very > simple public demo here > > http://issrg-testbed-2.cs.kent.ac.uk/ > > >> saying: "You are not authorized access to the requested information >> EXCEPT in the following circumstance(s): [drop-down list of >> circumstances]. >> > Hmm. where does the application get these circumstances from? Would they > be part of the policy and returned as obligations with the BTG response? > > Or would they simply be configured into the application? > > We have envisaged a different set of messages, which we called > Consequences, that would pop up to warn the user of the consequences of > breaking the glass. These would also be returned as obligations (to be > displayed to the user by the PEP) in the BTG response. > > We already have obligations on grant or deny, so could have them on BTG > as well. > > > If any of these applies to your request, select it and > >> then press the CERTIFY botton to certify that the circumstance applies >> to this access request. Otherwise press CANCEL. Note: this >> > transaction > >> and your certification will be recorded." >> > > The note you specify above is one of the Consequences that we envisaged. > > By encoding them as obligations in the policy you get much greater > freedom what to tell the user. > > > >> Well, I hope it would be a bit less wordy that that.<g> >> > I am sure if this feature was already implemented in PDPs, then > applications would be much more likely to make use of it > > regards > > David > > >> Martin >> >> >> -----Original Message----- >> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >> Sent: Tuesday, December 15, 2009 4:38 PM >> To: Smith, Martin >> Cc: Ludwig Seitz; xacml; Waterman, K. Krasnow<CTR>; Hammar, Patricia >> <CTR>; John, Anil; Tom Karygiannis >> Subject: Re: [xacml] Break the Glass policies >> >> Hi Martin >> >> at the NIST PMI conference in September the DoD had a similar concept >> > of > >> overriding access control for operational reasons, but the main >> difference to BTG is that in the DOD model a system component >> > evaluates > >> the operational need and either overrides or does not on behalf of the >> user. With BTG we are giving power back to the user to make the >> > informed > >> choice. One thing that our hospital trials uncovered is that you do >> > need > >> the audit and checks afterwards, otherwise it is hypothesised that >> > once > >> users learn that there are no consequences for always BTGing, they >> always will do it. >> >> The purpose for us defining the BTG model and third response it to >> > build > >> the complexity into the application independent PDP layer with >> consequent simplicity in the PEP layer, and simplicity in specifying >> > the > >> BTG policies. We therefore hope it will make this type of access >> > control > >> much easier to implement in all sorts of application scenarios. >> >> regards >> >> David >> >> >> Smith, Martin wrote: >> >>> David, all -- >>> >>> In looking at access policies based on formal policy authorities >>> > (like > >> >>> laws and frederal regulation) we've seen a number of cases where the >>> only practical source of a person or environmental "attribute" is >>> assertion by the requestor. The "BTG" attribute is an assertion that >>> an emergency situation exists. We also have come to the same >>> conclusion that you have (apparently), namely that ex-post >>> > enforcement > >> >>> (via audit of access logs) is a sufficient basis for enforcement for >>> many kinds of policies. >>> >>> Another general class of self-assertion situations is where a law or >>> policy says "you can share information 'for the purpose of' >>> >> something." >> >>> Example: passpost clerks can view personal passport records 'for the >>> purpose of' varifying information in the course of processing a >>> passport renewal application, (but not for other purposes, like >>> browsing the information of celebrities.) In many of these scenarios >>> > >>> one might imagine a data source for the attribute that did not depend >>> > >>> on self-assertion, but those data may not be available at least in >>> > the > >> >>> short run. >>> >>> I have not considered implementation of this enforcement strategy >>> (self-assertion plus log audit) to be a standards issue, so much as a >>> > >>> tooling issue (does a PDP product support pop-up requests for >>> self-asserted information?) But if making a BTG profile stimulates >>> vendors to add capability for collecting self-assertion data, I'm for >>> > >>> it! >>> >>> Martin Smith >>> US Department of Homeland Security >>> >>> >>> >>> -----Original Message----- >>> From: xacml-return-1875-martin.smith=dhs.gov@lists.oasis-open.org >>> [mailto:xacml-return-1875-martin.smith=dhs.gov@lists.oasis-open.org] >>> On Behalf Of Ludwig Seitz >>> Sent: Monday, December 14, 2009 2:52 AM >>> To: David Chadwick >>> Cc: xacml >>> Subject: Re: [xacml] Break the Glass policies >>> >>> Hi David, >>> >>> you might want to look at this: >>> http://portal.acm.org/citation.cfm?id=1263871 >>> >>> I think it is very similar to what you want to achieve. >>> >>> Regards, >>> >>> Ludwig >>> >>> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]