RE: [xacml] BTG sequence diagram

["Davis, John M." <Mike.Davis@va.gov>]

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.

In XSPA SAML, this environmental attribute is always contained in the SAML assertion and is called the "Purpose of Use".  The scenario would play out pretty much the same as Rich describes, however, on the deny, the user knows they have the ability to change the purpose of use to BTG and makes a conscious effort to do so.  

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

The establishment of the BTG policy set, may or may not cause privilege elevation, but in my opinion is not an essential element (e.g., you must still have the permission of "Medical Doctor" in the BTG Policy set).

Regards, Mike Davis, CISSP
Department of Veterans Affairs
VHA Office of Health Information 
Security Architect
760-632-0294

-----Original Message-----
From: rich levinson [mailto:rich.levinson@oracle.com] 
Sent: Friday, April 22, 2011 11:09 PM
To: Paul Tyson
Cc: Bill Parducci; XACML
Subject: Re: [xacml] BTG sequence diagram

Hi Paul,

I think we are basically in agreement at this point. I agree that there can
be as many btg attrs as necessary. There is a similar notion of consent
that users can apply to their own data, which is also fine grained in the
sense that consent can be specific users can see the consenter's data.

Both these concepts were demo'd in the RSA 2008 Interop, based on
the requirements and recommended techniques provided by the
VHA people: David S, Mike D, and Duane. We didn't have an actual
GlassMgr, but it was implicitly there.

     Thanks,
     Rich




On 4/22/2011 9:49 PM, Paul Tyson wrote:
>> On Fri, 2011-04-22 at 16:32 -0700, Bill Parducci wrote:
>> So Rich, in this scenario you are treating the BTG priv attribute as a Resource? If not, what does "permit" refer to?
>>
>> thanks
>>
>> b
>>
>> On Apr 22, 2011, at 4:25 PM, rich levinson wrote:
>>
>>> 	• The PEP in front of GlassMgr asks the PDP if this User is authorized to activate
>>> his BTG priv.
>>> 	• The PDP says yes, the User, according to Policy is authorized to perform this
>>> action (activate the User's BTG priv), and returns Permit.
> I had in mind a generic "BTG state", which I guess would be an
> environment attribute.  The user invokes a method of the GlassManager
> like "breakGlass()".  Upon finding that the user is authorized to
> execute this action, the GlassManager executes this method to set the
> environment attribute, btg-state, to "true".
>
> In an earlier email I asked for clarification on what, exactly, the
> glass protected: a person, a class of persons, a resource, a group of
> resources, or some combination of these?
>
> I guess generically you could have a boolean btg-state attribute for
> every action, resource, and subject (as well as an environment
> btg-state).  Then the user would invoke a method like "breakGlass('Bart
> Simpson')" to unprotect Bart Simpson's records.  The PIP would ask for
> the btg-state attribute pertaining to Bart's records.
>
> This is another area that needs to be clarified in David's BTG proposal.
>
> Regards,
> --Paul
>
>
>

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