Re: [xacml] Break the Glass policies

[Erik Rissanen <erik@axiomatics.com>]

Hi Dilli and Rich,

Yes, I intended that state is not put at the PDP. It's part of the PIP 
from the PDP's point of view, but that state should be controlled 
through policies (of some unknown form), rather than application code.

For instance, I imagine a policy about state as something like this:

IF client A record accessed THEN SET STATE subject.competing_clients = B

Note how we can express the dynamic separation of duties as a policy. I 
am not saying that this is the right form of policy and I don't know 
where the policy is and how it is enforced etc. But I hope you get the idea.

Then an XACML policy can have:

<Rule Effect="Deny">
<Condition>
      subject.competing_clients == resource-owner
</Condition>
</Rule>

I really don't have any good concrete proposals. It's just that 
something I have noticed is not handled so well by XACML today. I am 
sure there is plenty of academic research we can make use of.

Best regards,
Erik



On 2009-12-21 06:10, Dilli Dorai wrote:
> Agree with Rich.
> State would be maintained in ldap directory or an rdbms or things like 
> that for long lived state.
> State would be maintained in session for attributes that are short 
> lived, that is less than or equal to an authenticated user session.
> I thought PIP is the abstraction over ldap directory, rdbms, session 
> authorities etc.
> Given that, I do not really understand what we mean by the new term 
> stateful policy.
> Thanks.
> -Dilli
>
> Rich.Levinson wrote:
>> 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
>>
>> ---------------------------------------------------------------------
>> 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
>