[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
Hi Erik I agree it would be good to work on stateful policies for XACMLv4. We have been building state variables outside the PDP in a wrapper object that holds the various state variables and returns the current value to the PDP with the request context. This wrapper appears to be a PEP to the PDP and a PDP to the PEP, so the XACML request context can be passed between both interfaces. But in our latest BTG implementation (which uses this wrapper) we have found cases where it is not possible to know which precise state attribute value to pass to the PDP in the request context because there are several possible ones to chose from (e.g. there could be one state per role and the user presents several roles). It could be that our current design is wrong (i.e. we should be passing back the entire state array to the PDP rather than a single attribute value as we do now), or that the PDP does need to be stateful and hold all the state values, since only it knows which is the correct state value to use when it evaluates each of the various access rules. The outer wrapper does not have access to the policy rules, so it can never know which state should go with which rule. Any future design will have to address this specific issue. regards David Erik Rissanen wrote: > 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 >>>> >>>> >>> >> > > > --------------------------------------------------------------------- > 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 > -- ***************************************************************** 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]