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 Mike and Bill

On 25/04/2011 17:34, Bill Parducci wrote:
> On Apr 25, 2011, at 8:39 AM, Davis, John M. wrote:
>> Because, in this case, the obligation approach does not align with
>> the business need/policy.  The simple fact that one gets a deny
>> does not imply an obligation to automatically invoke a security
>> bypass.

you forget that one of the purposes of the BTG profile is to 
differentiate between a deny response and a BTG response, the latter 
being in between a grant and a deny. It is important that the PDP be 
able to give the BTG response to the user, as it is unreasonable to 
expect users to know what all their privileges are. It is the security 
officer/policy administrator who decides this and encodes it into the 
policy. The user finds out his privileges from the responses obtained 
from the PDP (which might change on an hourly or daily basis, according 
to the policy).

I therefore broadly agree with Bill's comments



  Since the PDP is not a state machine, the change of state
>> must be external, hence, the deny allows the user to reassess the
>> situation and apply either additional privilege to the request or
>> change the game by changing the policy set.
> I disagree on both counts. I do not see how the "business needs" are
> not met. I am not implying that the simple act of a Deny allows for
> access, rather that the conditions by which this determination is
> made is done within a single atomic action by the PDP. Subsequent
> requests (aka BTG Manager requests) are handled on the PEP in line
> with the terms of the Obligation that accompanied the original
> decision. Nothing has changed from the perspective of the requestor
> and as I mentioned in my previous note, the PEP is the best suited
> entity for performing things such as exception logging,
> notifications, etc. because only it can discriminate between the
> request for BTG and the Action be effected upon the Resource.
>> There is another aspect of BTG, in that the user is typically
>> required to assert acknowledgement to a set of conditions,
>> including an understanding that BTG is exceptional access and that
>> they are asserting this intentionally.  This gets messy, since the
>> obligation may need to be passed across boundaries to an external
>> requestor (you are now making a demand that the foreign system have
>> an interface with the requestor).  It seems simpler to me, to just
>> have a deny and leave it up to the user to figure out what they
>> need to do.
> This is no different than downstream systems needing to know the
> choreography of a follow-on request for BTG access. I argue that it
> is not any simpler because two coordinated requests must be made
> instead of one. So, unless you are suggesting that BTG access can be
> granted without a prior Deny, you now must spread state information
> across PEPs (or maintain "Layer 7 stickiness") to ensure cohesion of
> the access control transaction. Auditing in this scenario must also
> coordinate across multiple boundaries.
>> Furthermore, what would be totally acceptable in my mind, is for a
>> technology, such as XACML, to attempt to mandate to the business
>> side (regardless of what that is, healthcare, finance,
>> manufacturing etc.) that they MUST include a business
>> role/permission (such as BTG) in their information model in order
>> to make XACML work.    In fact, in healthcare (HL7 and ISO), there
>> is currently no such standard role, instead the standard is for
>> Purpose of Use defining a number of possible policy sets under
>> different conditions, (e.g. normal treatment, administrator access,
>> programmer access, research, marketing, etc.).  OASIS has existing
>> standards (XSPA SAML, XACML and WS-Trust) that have taken this
>> approach and defined the environmental attribute in the assertion.
> Acceptable perhaps for a Profile, but definitely not as part the Core
> specification IMO.
> b
> ---------------------------------------------------------------------
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]