Hi David, Unfortunately I will not be able to attend the mtg today, but do want to continue the discussion on thread. I think that we agree on what to me is the major point about the state being captured in the BTGstate attribute, and that what remains is some discussion on the options as to where the knowledge resides as to what "should" be done when the circumstance arises that a user is denied and at the same time it is known by this entity with the knowledge, that this user has an option to break the glass, and under what circumstances the glass will be broken. At this point in the scenaio I think there are some different use case assumptions that we are making. Mike and I appear to be coming from the position, that a user, such as a doctor, finds him/herself in a position where there is a patient w an emergency, and the doctor is denied access for normal reasons, but the doctor also knows that he/she has the privilege to override this "normal denial" in the case of emergency. The doctor would then assert the privilege and the request would be resubmitted w the BTGstate = true. I accept that there may be an alternate perspective where rather than the above scenario, there is some scenario where the user with the override privilege needs to have the override simply done on their behalf w/o their knowing that it is even happening, or at least that they are passive in the process and may only have a notice given to them that this priv raising had been automatically invoked for them. I have not given the latter scenario a lot of thought before now, but from the discussion am beginning to sense that this is where the differences still lie as to what should be in this profile. Thanks, Rich On 4/28/2011 6:57 AM, David Chadwick wrote: > 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 >>>>> >>> >> >