[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG sequence diagram
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. > > 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]