Re: [xacml] BTG sequence diagram

[Bill Parducci <bill@parducci.net>]

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.  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