Re: [xacml] BTG sequence diagram

[Bill Parducci <bill@parducci.net>]

On Apr 25, 2011, at 6:41 AM, Davis, John M. wrote:

> This discussion seems reasonable to me as far as it goes, however the BTG attribute is more than a privilege, it is in an environmental variable that tells the PDP which of a number of possible policy sets applies to the decision at hand.

I am still trying to figure out why is it that BTG must be defined by a separate set of Policies--using multiple request responses--and cannot be handled via a simple Obligation mechanism. If there is an Obligation in the Policy (on Deny) that stated "Must permit BTG access to group Doctors", this would compel the PEP to maintain state information on this request--the duration of which could be configurational or a component of the Obligation itself--that would be generated in the PDP based upon a simple attribute evaluation: is the requestor is a member of group Doctors? Should the request for BTG occur on the PEP within the TTL of the Obligation then the user would be granted access. The Obligation is "enforced" by the acceptance of BTG state information on the PEP. Non-synchronus Obligations are not a new concept :)

This solution may not be as elegant, but "heaviness" on the PEP is something that I think is unavoidable because for the use cases I have seen, there has to be something on the PEP that can act on in the absence of a PDP in a real world scenario anyway. (We are talking about potential life & death situations here, yes?)

[...]

> There is a business point here that users should not assert BTG (which in effect over rides "normal" policy) just because they want access.  Abuse of this attribute is not allowed.  This is inherent in asserting the extraordinary BTG POU, which will have the effect of triggering other security system events outside of the authorization system (e.g. enhanced audit, notification to system administrators, activation of a clock to limit the time the purpose of use is to allowed, etc).  

All of which are also addressable via Obligation, which I would argue is best handled by the PEP since it is the only component that knows not only if the BTG request was made, but if it was effected.

b