Re: [xacml] BTG sequence diagram

[rich levinson <rich.levinson@oracle.com>]

Hi Paul,

First, let me say that the reason I am replying to these issues is not specifically
to support David's proposal as submitted, but to try to help get an understanding
of what the core issues really are and then the TC should be able to better decide
what makes sense for next steps.

Also, I think the BTG scenario represents a common use case, that the TC generally
agrees is part of what XACML should be able to do with Policy definitions in
conjunction w the surrounding components: PEP, CH, PIP, PAP, APPL, where
these components are defined to have certain scopes of capabilitiess in the XACML spec
that the PDP admins can expect to incorporate in the Policy defns. (For example:

• the PEP submits requests and processes responses,
  
• the CH can front-end the PDP and provide some features such as
• pre-processing PEP requests and preparing single-decision requests
  to submit
  
• as well as "finding missing attributes during Policy evaluation",
• the PIP can provide these missing attributes (see the data flow diagram
  figure 1, section 3.1, particularly steps 5->10 that imply the capabilities in
  this and the prev bullet)
• the PAP can prepare and activate/deactivate policies
• the APPL provides the the resources that are being requested)

With respect to David's proposal, I have refrained from getting into the details,
which I have qualified in my earlier remarks, and particularly had avoided delving
into the use of the Obligations to facilitate this process.

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.

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)

In part 2, the following occurs:

1. The User, having been denied, 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 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:

1303499767.5905.30.camel@tristan" type="cite">

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