[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG sequence diagram
On 27/04/2011 17:27, Davis, John M. wrote: > Sure. Agree that the user does not need to know all their privileges. > They should, however, be able to know what they are doing and the > purpose of use for it and be able to assert such in a request. Based > upon that, their privileges as well as the entire decision context can > be determined (locally or via attribute assertion) including any actions > occurring outside of the XACML/authz concern. > > So they make a request under treatment-->deny. > They decide that the situation is significant enough to override and > reassert under BTG--> and again they are denied. This is because not everyone is allowed to BTG. By returning a BTG response to the first request of those subjects who are privileged enough, we tell them that they are allowed to BTG is they deem it to be a serious enough situation. This is the model already employed by XACML. Why does the XACML PDP return Indeterminate with a request for more attributes? Why not let the subject simply guess that this is what is needed, and let the subject try a bunch of additional attributes just in case he can get access with some of them? I therefore suggest that returning a BTG response is entirely consistent with the current XACML model regards David If their privileges are adequate under this pou > then the decision can be made--Allow. > > Regards, Mike Davis, CISSP > Department of Veterans Affairs > VHA Office of Health Information > Security Architect > 760-632-0294 > > > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Wednesday, April 27, 2011 8:06 AM > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] BTG sequence diagram > > Hi Mike and Bill > > On 25/04/2011 17:34, Bill Parducci wrote: >> >> On Apr 25, 2011, at 8:39 AM, Davis, John M. wrote: >> >>> Because, in this case, the obligation approach does not align with >>> the business need/policy. The simple fact that one gets a deny >>> does not imply an obligation to automatically invoke a security >>> bypass. > > you forget that one of the purposes of the BTG profile is to > differentiate between a deny response and a BTG response, the latter > being in between a grant and a deny. It is important that the PDP be > able to give the BTG response to the user, as it is unreasonable to > expect users to know what all their privileges are. It is the security > officer/policy administrator who decides this and encodes it into the > policy. The user finds out his privileges from the responses obtained > from the PDP (which might change on an hourly or daily basis, according > to the policy). > > I therefore broadly agree with Bill's comments > > regards > > David > > > Since the PDP is not a state machine, the change of state >>> must be external, hence, the deny allows the user to reassess the >>> situation and apply either additional privilege to the request or >>> change the game by changing the policy set. >> >> I disagree on both counts. I do not see how the "business needs" are >> not met. I am not implying that the simple act of a Deny allows for >> access, rather that the conditions by which this determination is >> made is done within a single atomic action by the PDP. Subsequent >> requests (aka BTG Manager requests) are handled on the PEP in line >> with the terms of the Obligation that accompanied the original >> decision. Nothing has changed from the perspective of the requestor >> and as I mentioned in my previous note, the PEP is the best suited >> entity for performing things such as exception logging, >> notifications, etc. because only it can discriminate between the >> request for BTG and the Action be effected upon the Resource. >> >> >>> There is another aspect of BTG, in that the user is typically >>> required to assert acknowledgement to a set of conditions, >>> including an understanding that BTG is exceptional access and that >>> they are asserting this intentionally. This gets messy, since the >>> obligation may need to be passed across boundaries to an external >>> requestor (you are now making a demand that the foreign system have >>> an interface with the requestor). It seems simpler to me, to just >>> have a deny and leave it up to the user to figure out what they >>> need to do. >> >> This is no different than downstream systems needing to know the >> choreography of a follow-on request for BTG access. I argue that it >> is not any simpler because two coordinated requests must be made >> instead of one. So, unless you are suggesting that BTG access can be >> granted without a prior Deny, you now must spread state information >> across PEPs (or maintain "Layer 7 stickiness") to ensure cohesion of >> the access control transaction. Auditing in this scenario must also >> coordinate across multiple boundaries. >> >> >>> Furthermore, what would be totally acceptable in my mind, is for a >>> technology, such as XACML, to attempt to mandate to the business >>> side (regardless of what that is, healthcare, finance, >>> manufacturing etc.) that they MUST include a business >>> role/permission (such as BTG) in their information model in order >>> to make XACML work. In fact, in healthcare (HL7 and ISO), there >>> is currently no such standard role, instead the standard is for >>> Purpose of Use defining a number of possible policy sets under >>> different conditions, (e.g. normal treatment, administrator access, >>> programmer access, research, marketing, etc.). OASIS has existing >>> standards (XSPA SAML, XACML and WS-Trust) that have taken this >>> approach and defined the environmental attribute in the assertion. >> >> Acceptable perhaps for a Profile, but definitely not as part the Core >> specification IMO. >> >> b >> >> >> --------------------------------------------------------------------- >> >> > 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]