Hal,
Yes, I agree that a special entity with the explicit purpose of
maintaining authorization state would be something good to add. It's
not unusual for real world access control needs to depend on state,
which may be itself affected by an access decision. XACML should
support this, but not in the PDP itself.
Erik
On 02/24/2011 06:04 PM, Hal Lockhart wrote:
3b21921c-dfc7-4cff-acf1-6b6524d463bb@default"
type="cite">
When we say that the PDP is stateless, what is meant
is that no state is carried by the server from one decision to the
next. Policy decisions are purely a function of policies in force and
the content of the request context.
I agree with the general view that this is a valuable
property which not should be lightly changed across the board. However,
I am keeping an open mind on the desirability of explicitly defining
entities within the access control architecture which do maintain
state.
For example, the RBAC profile as it currently exists
implies some kind of stateful mechanism to keep track which dynamic
roles have been enabled. The exact mechanism was deliberately not
specified as it was recognized that many designs were possible.
Hal
Hi Mike, Erik, Paul, and David,
Here's my two cents on what I've taken from the emails on this
thread, David's BTG profile and protocol description.
I agree w Erik's statement that the XACML model does not have
state built in, and that there is not yet a compelling reason to add it.
However, my interpretation of "state" is wrt the Policy definitions.
i.e. the Policy defns themselves are "static".
However, for "Policy evaluation", the "state" is the RequestContext,
namely whatever values are in the Attributes in the RequestContext
at Policy evaluation time may be regarded as the "state".
So, for "BTG", what I see as the essential ingredient is the defn of
a BTG-State Attribute, that can be supplied by the PEP, or some
PIP that supplies it to an attribute finder during policy evaluation.
Testing the attribute would be triggered by its presence in a Policy
with it MustBePresent xml attribute set to true, and the Policy
should be defined, so that the BTG-State Attribute is not tested
unless the request is not permitted without it.
This is equivalent to what we did in the RSA-2008 Interop, where
the "BTG-State" attribute was "hl7:pea-001", which would allow an
external user access, where they would otherwise be denied.
i.e. the presence of hl7:pea-001 effectively changed the "state"
of Policy evaluation, which enabled BTG logic to be applied.
With respect to David's documents, I basically agree with the
approach, except for statements like in the protocol descr step 8,
where it says: "The PDP sets the relevant BTG-state variable
to true ...".
I think it is fine to return an Obligation as the Profile describes,
and that this be used as the basis of the User obtaining a
"BTG-State" Attribute, which can be submitted in the
follow-up request. I think the presence of this attribute
is sufficient "state" for the Policy to evaluate properly.
Thanks,
Rich
Davis, John M. wrote:
EABFCFD64432124F98EF01B2C3E87F6D098EB79A@VANCRMSGW1.vha.med.va.gov"
type="cite">
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
|