OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] BTG sequence diagram

Hi David,

I will try to clarify in line, but do not think at this point there is any
fundamental disagreement, except possibly the dependencies necessary
to construct the functionality.

Actually, to keep focus, I will just respond to your first comment, as after
writing the response I think the rest of the points depend on whether
there is agreement on the first point.


On 4/27/2011 10:50 AM, David Chadwick wrote:
> Hi Rich
> Comments on your message flow below
> On 23/04/2011 00:25, rich levinson wrote:
>> 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.
> I disagree with this, see my previous message to Paul which shows why. 
> If the policy contains an obligation to update the BTGstate when the 
> breakGlass operation is granted, then no new user service (such as 
> Glass Manager) is needed and the existing PEP, coupled with the 
> standard Obligations Service, can handle both normal operations and 
> breakGlass operations.
I think we are in agreement that there exists somewhere a managed entity 
that has
custody of an Attribute that we are calling "BTGstate". i.e. the state 
exists, and in the
context of BTG functionality, that state can be changed, which will 
affect the behavior
of Policy evaluation.

All the Policy needs is to know the value of this attribute called 
"BTGstate" and then
the Policy can include logic depending if the value is true or false.

My claim is that this is the "core functionality" of BTG. The mechanics 
of who or what
actually causes the state to change is external to XACML Policy. The 
Policy just needs
to know the value of the state, and that the state is provided by a 
certain Issuer, etc.,
all of which can be provided within a XACML Attribute.
>> 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)
> It is important that the policy has 3 classes of user, namely: those 
> who are granted access, those who are denied access, and those who 
> have BTG access rights. The administrator must be able to say which 
> users are in which class and be able to control this in the policy. 
> Therefore message 5 above should return the BTG response and not a 
> standard grant or deny response, otherwise you are still left with 
> only 2 classes of user in the policy.
>> In part 2, the following occurs:
>>    1. The User, having been denied,
> The user, having received the BTG response knows.....
> We do not put the requirement on the user to know if he has BTG 
> privileges or not, but rather on the policy writer to specify who has 
> which privileges. This is the normal situation in writing policies 
> isnt it? If users knew beforehand which resources they could access 
> and which they could not, why would we need a policy?
>  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
> No obligations are needed if you have a special Glass Manager, but if 
> yoiu use a standard PEP then an obligation is needed to update the BTG 
> state database
> regards
> David
>>       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:
>>> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]