[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
Hi Erik,
I found your email to be a very interesting and instructive analysis.
I am still not convinced that the PDP, itself, needs to maintain state.
Why would we not store these "dynamic attributes" in some sort of PIP?
Possibly we could have a dynamic attribute profile that described the
operation of such a PIP.
+1 for putting this on the immediate post-3.0 stack.
Thanks,
Rich
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]