[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG comment
Hi Mike The idea that I was proposing was not that the policy in the PAP would change, but rather the policy would remain fixed for all of the examples throughout the multiple authz requests that are made. What would change is the values of the various attributes that are stored in StateDB, and this by definition, is a change of state of the system. So using the 3 examples with static policies and variable attributes we would have On 14/03/2011 20:26, Davis, John M. wrote: > David, > > I like your examples but suggest that the changes in the attributes need > to drive a policy change in the PAP. Using your three examples: > > 1. *support withdrawals from a credit card machine up to a daily limit*. > This could be handled in the policy based upon a value of is “credit > granted <daily limit”? Credit Granted would be an attribute that starts at value zero each day, and is incremented each time the user withdraws some money. The policy remains fixed with the rule If Credit Granted + Amount requested < Daily Limit then grant An obligation attached to the grant mandates that the StateDB is updated so that Credit Granted = Credit Granted + Amount Requested When this limit is reached access is denied but > there is really no state change. Again, if the user changes the policy > to a state change where the user ”state” is set to “can only request > credit extension” by agreeing to some conditions then the policy state > is changed to a new rule that applies only if the new conditions are met. > > 2. *block a user's account after 3 concurrent denies*. This is the same. > If “concurrent retries <3” then allow else deny. In this case No of Denies is an attribute that is initially set to Zero. If a request is denied then an obligation accompanying the deny response requires that the StateDB be updated so that No of Denies = No of Denies + 1. If a request is granted then a corresponding obligation requires the StateDB to set No of Denies = 0 A fixed policy rule states If No of Denies GE 3 then Deny request. An accompanying obligation requires the system to block this user's account. It will then require administrator action to unblock the account and set No of Denies to 0. 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 > -- ***************************************************************** 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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]