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 Rich

Comments on your message flow below

On 23/04/2011 00:25, rich levinson wrote:

LARGE CUT HERE

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


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

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
School of Computing, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************


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