[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG sequence diagram
Hi Rich On 27/04/2011 16:36, rich levinson wrote: > Hi David, > > I will try to clarify in line, but do not think at this point there is any > fundamental disagreement, except possibly the dependencies necessary > to construct the functionality. > > Actually, to keep focus, I will just respond to your first comment, as > after > writing the response I think the rest of the points depend on whether > there is agreement on the first point. > > Thanks, > Rich > > > On 4/27/2011 10:50 AM, David Chadwick wrote: >> Hi Rich >> >> Comments on your message flow below >> >> On 23/04/2011 00:25, rich levinson wrote: >> >> LARGE CUT HERE >> >>> So, let me flat out say: "I think the Obligations are superfluous and do >>> not have >>> any place in the core BTG capability". There is nothing "wrong" with >>> them being >>> there, but, imo, they are unnecessary. >> >> I disagree with this, see my previous message to Paul which shows why. >> If the policy contains an obligation to update the BTGstate when the >> breakGlass operation is granted, then no new user service (such as >> Glass Manager) is needed and the existing PEP, coupled with the >> standard Obligations Service, can handle both normal operations and >> breakGlass operations. > <Rich> > I think we are in agreement that there exists somewhere a managed entity > that has > custody of an Attribute that we are calling "BTGstate". i.e. the state > exists, and in the > context of BTG functionality, that state can be changed, which will > affect the behavior > of Policy evaluation. Agreed > > All the Policy needs is to know Disagree. See my message to Mike. The policy also needs to know how to return a BTG response. The policy also should know when the state should be updated. the value of this attribute called > "BTGstate" and then > the Policy can include logic depending if the value is true or false. Also agreed > > My claim is that this is the "core functionality" of BTG. The mechanics > of who or what > actually causes the state to change is external to XACML Policy. As I pointed out in a previous message, something somewhere has to know this. You can either make it external to XACML, with a new kind of PEP (the glass manager) which requires apps/subjects to behave differently for different actions, or make it internal to XACML via an obligation which says when the state has to be updated. I prefer the latter since all the required components already exist. regards David The > Policy just needs > to know the value of the state, and that the state is provided by a > certain Issuer, etc., > all of which can be provided within a XACML Attribute. > </Rich> >> >> >>> >>> That being said, let me quickly stride thru your sequence diagram, and >>> call out >>> what appear to me to be the important points. The diagram is in 3 parts, >>> which >>> we can call 1, 2, and 3. >>> >>> In part 1, the following occurs: >>> >>> 1. The User submits a request to a WebApp for a Resource. >>> 2. The PEP in (in front of, whatever) the WebApp sends XACML request >>> to PDP >>> 3. The PDP finds that it needs "btgState" to complete eval, so has CH >>> get it from >>> the PIP that gets it from GlassMgr >>> 4. PIP gets value from GlassMgr and returns btgState = false to PDP >>> 5. PDP finishes eval and returns Deny (with or without Advice, imo) >> >> It is important that the policy has 3 classes of user, namely: those >> who are granted access, those who are denied access, and those who >> have BTG access rights. The administrator must be able to say which >> users are in which class and be able to control this in the policy. >> Therefore message 5 above should return the BTG response and not a >> standard grant or deny response, otherwise you are still left with >> only 2 classes of user in the policy. >> >>> >>> In part 2, the following occurs: >>> >>> 1. The User, having been denied, >> >> The user, having received the BTG response knows..... >> >> We do not put the requirement on the user to know if he has BTG >> privileges or not, but rather on the policy writer to specify who has >> which privileges. This is the normal situation in writing policies >> isnt it? If users knew beforehand which resources they could access >> and which they could not, why would we need a policy? >> >> >> knows that it has a BTG priv, and so >>> submits >>> a request to the GlassMgr to activate the privilege. >>> 2. The PEP in front of GlassMgr asks the PDP if this User is >>> authorized to activate >>> his BTG priv. >>> 3. The PDP says yes, the User, according to Policy is authorized to >>> perform this >>> action (activate the User's BTG priv), and returns Permit. >>> 4. The GlassMgr then "activates" the User's BTG priv, setting >>> btgState=true. >>> 5. The GlassMgr then returns notice to the User that the User's btg >>> priv is active >>> (again, imo, there is no need for any obligations) >>> >>> In part 3, the following occurs: >>> >>> 1. The User reattempts the request in part 1 step 1. >>> 2. PEP sends req to PDP, same as part 1, step 2. >>> 3. PDP again finds it needt "btgState" and uses CH, same as part 1, >>> step 3. >>> 4. PIP again gets value from GlassMgr, but this time returns btgState >>> = true to PDP. >>> 5. PDP finishes eval and returns Permit (again, imo, no obligations >> >> No obligations are needed if you have a special Glass Manager, but if >> yoiu use a standard PEP then an obligation is needed to update the BTG >> state database >> >> regards >> >> David >> >>> are needed), and >>> this time the WebAppl returns the Resource to the User. >>> >>> Based on the "core description" as I've described above, one can then >>> add Obligations >>> and Advice to "help things along", but they are not needed, imo. >>> >>> I believe that presented this way, the scenario does not involve any of >>> the "risks" >>> you mentioned, and, I don't think it does anything "out of the >>> ordinary", except >>> takes advantage of the built in XACML capabilities to call out for >>> external attrs >>> as described in the data flow diagram of section 3.1 of 3.0 core spec. >>> >>> Thanks, >>> Rich >>> >>> >>> On 4/22/2011 3:16 PM, Paul Tyson wrote: >>>> This is to respond to David Chadwick's notes [1] and [2] and to try to >>>> explain what I believe is the correct sequence of a BTG episode. >>>> >>>> In [1], David describes three evaluation scenarios: >>>> >>>> 1. "If action = read and role=Doctor and resource=medical record and >>>> BTGstate = True then grant access" >>>> >>>> No problem here--it corresponds to the last user interaction in >>>> attached sequence diagram. >>>> >>>> 2. "If Action=SetBTG and .... then grant with obligation set >>>> BTGstate to >>>> True in StateDB." >>>> >>>> I guess it could work this way, but if we identify a "GlassManager" >>>> service, the user would request the GlassManager to break the glass, >>>> who >>>> in turn would make an authorization request, verify permission, and >>>> take >>>> the action, and return an appropriate message (perhaps including >>>> obligations) to the user. >>>> >>>> 3. "If Action=ResetBTG and .... then grant with obligation set BTGstate >>>> to False in StateDB" >>>> >>>> I did not show this interaction, but it would look like the illustrated >>>> interaction for "breakGlass". >>>> >>>> Now, more generally, to respond to [2], refer to the attached sequence >>>> diagram, which represents a rather purified view of the components and >>>> their interactions. Many variations on this are possible, but the >>>> variations I do not want to sanction with a standard are the ones that >>>> would have the PEP, PDP, or PIP doing things that degrade their >>>> functional independence or extend their specified behavior, or that >>>> would overload the XACML request/response mechanism with additional >>>> meanings. David's last formal proposal [3] has all of these risks, >>>> although subsequent discussion has mitigated some of them. >>>> >>>> One feature of that proposal that has not been discussed much is the >>>> initial BTG obligation (section 2.1). This would require the PDP not >>>> only to apply the policy to the original request (for data), but >>>> also to >>>> find and apply a policy to a hypothetical request to break the glass. I >>>> don't know of a policy feature to induce this behavior, nor any type of >>>> stanard request that could do this. The policy could return the state >>>> of the glass as an obligation attribute, but that is all it could do >>>> using standard features. >>>> >>>> Maybe if we can agree on the scenarios we want to support (using >>>> sequence diagrams for common understanding) we would have a better >>>> chance of identifying opportunities for standardization around BTG. >>>> >>>> Regards, >>>> --Paul >>>> >>>> [1]http://lists.oasis-open.org/archives/xacml/201104/msg00031.html >>>> [2]http://lists.oasis-open.org/archives/xacml/201104/msg00033.html >>>> [3]http://lists.oasis-open.org/archives/xacml/201102/msg00017.html >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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]