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

On 27/04/2011 16:36, rich levinson wrote:
> 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.
> Thanks,
> Rich
> 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.
> <Rich>
> 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

Disagree. See my message to Mike. The policy also needs to know how to 
return a BTG response. The policy also should know when the state should 
be updated.

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

Also agreed

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

As I pointed out in a previous message, something somewhere has to know 
this. You can either make it external to XACML, with a new kind of PEP 
(the glass manager) which requires apps/subjects to behave differently 
for different actions, or make it internal to XACML via an obligation 
which says when the state has to be updated. I prefer the latter since 
all the required components already exist.



> 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.
> </Rich>
>>> 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]