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 Paul

thankyou for your sequence diagrams. They are very helpful, and similar 
to what I had in mind. If you

a) turn your Glass Manager into the BTG State Handler,
b) add an Obligation Service to the web app (PEP) as in standard XACML, and
c) allow the web app to handle the breakGlass operation, then

if the PDP returns an obligation with a grant to the breakGlass request, 
the web app can call the Obligation Handler to update the state in the 
BTG State Handler. Then our two diagrams would have the same 
functionality. In other words, you are replacing an obligation to update 
the BTG state, with a request to the Glass Manager instead of to the web 
app. Since the former knows that on grant it must update the state then 
no obligation is needed. The web app on the other hand knows nothing 
about updating the state, so that is left to the Obligations Service 
(and the policy rule). Since the application developer must develop both 
the Web App and the Glass Manager, and say what policies are needed, it 
would be his choice which architecture to use.

Neither of the above designs "degrade their functional independence or 
extend their specified behavior" since the web app is behaving like a 
standard PEP.

Your design on the other hand requires special operation handling since 
the user or app need to know to send breakGlass operations to a 
different PEP than the other operations. My design requires no such 
special operation handling.

You also say "One feature of that proposal that has not been discussed 
much is the initial BTG obligation (section 2.1).". In fact this 
requires no special behaviour by the PDP once we have an agreed BTG 
return code. The rule would simply be

  "If action = read and role=Doctor and resource=medical record and
BTGstate = False then return code = BTG"

One of the things I want the group to standardise is how the BTG return 
code is constructed. Various options have been discussed, and using a 
Deny and BTG obligation is just one of them. I dont really mind how the 
return is signalled. The important thing is that it is standardised in a 
profile so that implementers know how to do it.



On 22/04/2011 20:16, 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]