OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] BTG comment


Hi Rich,

What I meant with my comment, and which I think is what Paul is also objecting to, is that it might not be a good idea to let the request/response protocol itself drive the state changes in the "StateDB".

With "letting the request/response protocol drive the state changes in the StateDB" I mean roughly that the stateDB would be associated with triggers, which, when they see particular attribute values in a request and particular decision, the would change the state of some attribute in the StateDB. For instance, if an incoming request to the PDP says action-id = "BTG" and the response says "Permit", then the attribute "btg-in-process" would be set to true. This would be done within the StateDB/PDP combo, without involvement of the PEP.

This would have two undesirable characteristics:

1. It is harder to understand the behavior of the PDP since it is no longer idempotent from the perspective of the PEP.

2. From a more fundamental level, from the point of view of the use cases, it is doubtful whether it makes sense to have a trigger like this since the fact that a PDP has permitted something is not the primary event which matters. Rather it is usually the enforcement action in the PEP which matters for the state change.

This latter point is perhaps easier to understand in the context of a simple banking example: an application access is made to withdraw $100 from an account. The PEP intercepts this and asks the PDP. The PDP has a policy which, among others, requires that the balance of the account >= $100. The balance of the account is in this example an attribute maintained in the "StateDB". Let's say the balance equals $200 so the PDP permits the action.

Now at this stage, it would not make sense to reduce the balance of the account by a StateDB trigger since the transaction has not been completed. It has just been permitted. There may be other reasons for the transaction to be aborted or rolled back, and we would gain nothing by involving the PDP and the StateDB in this.

I have not analyzed the BTG case in detail, but it appears similar to me, that is, it makes more sense to change the state in the PEP and/or application.

And I have not come up with any good use case or example where this kind of StateDB and triggers would make sense.

Best regards,
Erik

On 2011-03-18 23:23, Rich.Levinson wrote:
4D83DB58.80609@oracle.com" type="cite"> Hi Paul,

I am not sure I understand the objections you are raising.  I have put comments
inline below, trying to respond to the points you have made.

As I have indicated in prev emails, I believe the proposal is using standard mechanisms
and not introducing any "state" to the PDP, other than the implicit state of the request
context which already exists, nor is it doing anything significantly different from techniques
we have already used in the RSA 2008 Interop, where we had policies for
emergency conditions based on an emergency-override attribute that a subject
could obtain thru some external mechanism from a trusted authority that could
then be submitted with the request. If you are interested the details of that Interop
are in the XACML Repository:
http://www.oasis-open.org/committees/document.php?document_id=28030&wg_abbrev=xacml

(In the doc description of the zip file at the above URL, it is item #2 that contains
the specification with details of requests and responses and policies in section 2.2.4
that describes the "Emergency Access Use Case".)

    Thanks,
    Rich

Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">
Erik seems to appreciate my objection to David's BTG proposal, which has
nothing to do with stateful or stateless PDPs, but with my desire to
restrict (or at least not to sanction) the use of the request/response
mechanism to directly change attribute values in the request context.
  
In the proposed approach, there is only one request context, which is initially populated by
the request from the PEP. It can subsequently have "additional" attributes set during Policy
evaluation if a referenced attribute is not present and the PDP calls out to a PIP to supply
the attribute.

The response does not get created until policy evaluation has completed, and once created,
the request context is no longer used for anything.

i.e. I don't understand what you mean when you refer to your "desire not to sanction the use
of the request/response mechanism to directly change attribute values". That is not what is
happening here. The original attributes are left intact. Additional attributes may be "read"
from a PIP.
3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">
If one wants to analyze the request context one should only have to look
at how the PIP is implemented (and of course the attribute instances
conveyed by the original request).  Introducing a distinguished
action-id value or specialized attribute id that has the power to modify
the request context makes it harder to analyze.  The only virtue of this
approach is convenience, and it seems a slim virtue at that.  It should
be possible to set up a 3rd-party service that can communicate with the
PEP and PIP as necessary to set and retrieve BTG state.
  
I think that is exactly what the proposal is. The "StateDB" would generally sit behind a PIP and
the Policy can request the BTG state attribute, or the PEP can get it in advance and send it in.
3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">
The patient's medical condition, whether or not the building is on fire,
and the client's bank account history are all things that are outside
the scope of XACML.  Information about them should come into the XACML
system in the normal ways: either from a trusted source via the PEP, or
a PIP.
  
I don't believe there is anything in this proposal at variance with this. All information is coming
in normal ways thru trusted PEP or PIP.

3898C40CCD069D4F91FCD69C9EFBF096060512EB@txamashur004.ent.textron.com" type="cite">
Regards,
--Paul

-----Original Message-----
From: Davis, John M. [mailto:Mike.Davis@va.gov] 
Sent: Friday, March 18, 2011 13:34
To: Rich.Levinson; Erik Rissanen; David Chadwick
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] BTG comment

I think we are agreed.  The attributes of the StateDB can refer to both
the policy set and the attribute used to evaluate the request, eg.
"Normal Healthcare Rules", or "BTG Rules" plus "Normal Healthcare
attributes" or "BTG Attributes".  The implication is that the user
request would include the requester purpose of use (setting the state),
and associated attributes which combined with existing attributes about
the (from various sources) relative to that POU allows for decision.
User asserted information, and in particular purpose of use,  is
included in the XSPA profiles of XACML, SAML and WS-Trust as a mandatory
attribute.  

Regards, Mike Davis, CISSP
Department of Veterans Affairs
Office of Health Information 
Security Architect
760-632-0294


-----Original Message-----
From: Rich.Levinson [mailto:rich.levinson@oracle.com] 
Sent: Friday, March 18, 2011 10:13 AM
To: Erik Rissanen; David Chadwick
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] BTG comment

Hi Erik, Paul, Mike, Hal, and David,

I believe David's position:
http://lists.oasis-open.org/archives/xacml/201103/msg00017.html

is consistent with the position I recommended:
http://lists.oasis-open.org/archives/xacml/201102/msg00042.html
and originally, when this discussion began last year:
http://lists.oasis-open.org/archives/xacml/201011/msg00040.html

so, I think David and I are pretty much in agreement on the concepts
at this point.

The bottom line is that any "state" that is evaluated by the PDP
policies
is contained in the request context in attributes. Who maintains those
attributes and how they get into the request context is dependent on
the system designers, and the Policy designers. But the PDP, itself,
should not require any changes from XACML 2.0 or 3.0 to implement
this.

 From my perspective, "StateDB" is nothing more than an attribute
repository, whose attributes can be referenced in Policy statements.

Also, from my perspective, a "profile" might be useful, but is not
required
for anyone to use this system design strategy with either XACML 2.0 or
XACML 3.0.

    Thanks,
    Rich


Erik Rissanen wrote:
  
Paul, all,

I am not sure if there is a motivation for it, but there would be a 
need for an XACML state component if the desired behavior is that 
"state is changed when an access decision says Permit" (Or deny). This
    

  
is distinct from "state is changed when an access to a resources is 
performed".

In the bank case, clearly it should be the latter case, that is, the 
PEP enforces the Permit, by which the banking application will change 
the amount in the account.

I cannot think if a specific real world example of the case where the 
decision by the PDP itself would cause a state change.

Also It might be useful from a purely practical implementation point 
of view though. Not sure. Anybody?

Best regards,
Erik

On 2011-03-15 21:42, Tyson, Paul H wrote:
    
The 3rd example differs from the previous 2 in that the XACML request
      
is
  
simultaneously *changing* the request context and requesting
      
permission
  
to perform an action.

Nothing in the XACML spec prevents this (as far as I can see), but it
overloads the request message unnecessarily.  I would not want to
sanction this behavior in an official profile.  I believe it
      
simplifies
  
analysis to assume that the request/response sequence is idempotent
      
with
  
respect to the request context.

Nothing prevents an implementation from using other communication
channels to modify the environment to cause a change in the
      
evaluation
  
context.  In the bank account examples, it would seem a very poor
      
design
  
to make the XACML system update account information--surely that
      
happens
  
outside of the XACML system.  Each time a request is received, it
evaluates with new values for withdrawal amount and frequency.  Why
shouldn't the same design principle apply to a BTG attribute?

I raised this and other concerns in my note of 22 February 2011:
http://lists.oasis-open.org/archives/xacml/201102/msg00037.html.

Regards,
--Paul

-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
Sent: Tuesday, March 15, 2011 15:10
To: Davis, John M.
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] BTG comment

<<<first 2 examples omitted - pht>>>

   All you need is the
      
value of the current attribute for retry count. No change of state.
However, if you link this to a system change that says the user must
        
now
      
authenticate by providing "Mothers maiden name" and other personally
known information, then the policy state has changed from "Normal
authentication used" to "Alternate authentication used". In other
        
words
      
access policies may change under alternate (can only reset
        
password).
  
3*. BTG*. Here we require the system to go from a "Normal" access to
        
a
  
new rule set "BTG" which would have new expectations of system
        
Again we can have a fixed policy with the following condition
      
attached
  
to a rule

If BTG = True then grant access

We can have the following fixed rules as well

If Action=BTG and .... then grant with obligation set BTG to True in
StateDB.

If Action=ResetBTG and .... then grant with obligation set BTG to
      
False
  
in StateDB

regards

david


      
performance caused by changing the policy set referenced by the PAP.
        
For
      
example, the rule set for patient privacy might be much different
        
for
  
normal "treatment" than for "emergency" where imminent harm or death
        
was
      
involved.

Regards, Mike Davis, CISSP
Department of Veterans Affairs
Office of Health Information
Security Architect
760-632-0294


-----Original Message-----
From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
Sent: Monday, March 14, 2011 10:20 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] BTG comment

Hal, Erik

is some sort of consensus arising that we need an entity in the
        
XACML
  
model (call it a StateDB for now) that holds the state of the system
        
in
      
the form of one or more attributes, whose values can be changed.
        
When
  
an
      
attribute value changes this represents a state change of the
        
system.
  
The PDP is and remains stateless.

The request context carries the current state of the system to the
        
PDP.
      
A component of the XACML system (might be a PIP, or it might be
something new) picks up the current state of the system from the
        
StateDB
      
and inserts these attributes into the request context for passing to
        
the
      
PDP.

When certain authz decision requests are granted (or denied) this
        
might
      
cause a change in the state of the system. A new component is needed
which updates the StateDB when this occurs.

This type of state based system is more generic than BTG, and can
incorporate BTG as one of its use cases. You can for example use
        
this
  
type of state based system to
- support withdrawals from a credit card machine up to a daily
        
limit,
  
- block a user's account after 3 concurrent denies,
- implement BTG by setting the glass to broken when a user is
        
granted
  
permission to break the glass

Does this also answer Mike's suggestion that BTG is an example of
something more generic?

regards

David


On 24/02/2011 17:48, Erik Rissanen wrote:
        
  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:
          
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

-----Original Message-----
*From:* Rich.Levinson
*Sent:* Wednesday, February 23, 2011 11:57 AM
*To:* Davis, John M.
*Cc:* erik@axiomatics.com; xacml@lists.oasis-open.org
*Subject:* Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda
10 February 2011 TC Meeting]

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:
            
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.p
      
hp


              
-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security School of Computing,
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
  
*****************************************************************


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


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