Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February 2011 TC Meeting]

["Davis, John M." <Mike.Davis@va.gov>]

I still think BTG is a  subset of a more general use case. 

Following along with the obligation, my impression was that this must be followed with an ageement to abide by the obligation constraints, e.g. a "promise".  The promise  could act to tell the PDP to change the policy set (in this case to BTG).  With the "state" change the decision is now correct. 

Mike Davis

----- Original Message -----
From: Erik Rissanen <erik@axiomatics.com>
To: xacml@lists.oasis-open.org <xacml@lists.oasis-open.org>
Sent: Wed Feb 23 04:42:41 2011
Subject: Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February 2011 TC Meeting]

Hi Paul and Mike,

I agree, but isn't this exactly what David is proposing? That is how I 
understand it, at least for the "PEP state" mode. The other alternative 
with the PDP maintaining state is something I don't think is a good idea.

To make David's proposal better, it needs:

- Drop the PDP state approach since this goes against the capability of 
the XACML model which does not have a state built in.

- Define identifiers for at least the BTG obligation/advice (advice is 
better, but for XACML 2.0 an obligation needs to be used), the action-id 
for breaking glass (as well as giving some kind of direction of what the 
BTG request should look like in relation to resources being accessed).

- It would be nice with a full, worked through example.

Best regards,
Erik

On 2011-02-23 05:06, Davis, John M. wrote:
> Concur with Paul's analysis.  We also see BTG as a state change.
>
> Regards, Mike Davis, CISSP
> Department of Veterans Affairs
> Office of Health Information
> Security Architect
> 760-632-0294
>
> -----Original Message-----
> From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Sent: Tuesday, February 22, 2011 7:48 AM
> To: David Chadwick; xacml@lists.oasis-open.org
> Subject: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February
> 2011 TC Meeting]
>
> I have some reservations about David's BTG proposal, primarily because
> the semantics are not well specified, and because it muddies the
> distinction between what should happen within the XACML system, and what
> should happen outside of XACML.
>
> Obligations, as currently defined, require the PEP to take some action
> prior to executing or acting on the PDP's decision for a particular
> request.  The proposed BTG obligation is entirely different: it says
> "you can't have access, but you can break the glass if you choose".  We
> added Advice in XACML 3 to accommodate this sort of
> message-passing--messages which may or may not have anything to do with
> the original request or the decision.  I don't think the TC should
> encourage the use of Obligations for anything other than what they are:
> an obligation to discharge certain actions regarding the PDP's decision.
> This is the only way to assure predictable system behavior--or to detect
> a faulty system.
>
> As we discussed on the last call, the scope and definition of "glass"
> should be specified.  If not, we are just standardizing some features of
> the request/response protocol without knowing what effect these features
> have, either on the PDP or the PEP.  Does the glass cover a specific
> request, a specific class of subjects, a class of resources, or what?
> Or is glass-condition just another attribute in the request context,
> whose effective meaning is given by the policy rules?
>
> However you define glass-condition, it will have to be implemented as a
> XACML attribute in the request context, or as some extra-xacml
> functionality.  Either way, you are now using the XACML request
> mechanism to change the policy evaluation state directly.  While this
> isn't prohibited by the standard, it makes it harder to reason about the
> behavior of the system.
>
> David's "BreakTheGlass" action-id is egregious in that it is not just a
> request for permission to do something (outside the XACML system)--it is
> a directive to change the state of the policy evaluation with regard to
> a particular (non-XACML) resource, subject, or action.  Now, if state is
> maintained in PEP, you could say this is a normal request, but
> nevertheless it has muddied the distinction between requests for
> permission to do something (outside of XACML) and directives to do
> something "inside" of XACML.
>
> I would favor one of two alternative approaches (or some combination):
>
> 1. Simply return an Obligation (along with a Permit decision) if the
> requestor is authorized to "break the glass".  The PEP would be obliged
> to display the list of consequences associated with accessing the
> resource, and the user could choose to accept the consequences and see
> the resource, or cancel the request.  The consequences could include
> changing the state of the system to allow access to other resources, or
> allow other people to see the same resource, or whatever the business
> meaning of "break the glass" carries in a specific application.  The
> obligations would be discharged outside the XACML system.  (I'm not sure
> that this approach really warrants a standard profile, unless we just
> want to provide a distinguished obligation id value for BTG.)
>
> 2. Write policies specifically to allow "break-the-glass" actions to
> certain subjects in certain conditions.  The PEP would request
> permission to break the glass, and if allowed would use some non-XACML
> mechanism to change the policy evaluation state.  Obligations could be
> returned with the decision to advise user of the consequences.  Then the
> application would request access to the desired resource.  (Again I
> question whether this is worthy of standardization, unless we want to
> name a distinguished "break-the-glass" action id.)
>
> Either of these approaches would meet the BTG use case without altering
> the semantics or conventional usage of XACML.
>
> Regards,
> --Paul
>
>> -----Original Message-----
>> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
>> Sent: Thursday, February 10, 2011 05:22
>> To: xacml@lists.oasis-open.org
>> Subject: Re: [xacml] Proposed Agenda 10 February 2011 TC Meeting
>>
>> Dear All,
>>
>> in preparation for this evening's call, I attach a revised version of
>> the BTG profile for you consideration
>>
>> regards
>>
>> David
>>
> <snip>
>
> ---------------------------------------------------------------------
> 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
>


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