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

On 27/04/2011 17:27, Davis, John M. wrote:
> Sure.  Agree that the user does not need to know all their privileges.
> They should, however, be able to know what they are doing and the
> purpose of use for it and be able to assert such in a request.  Based
> upon that, their privileges as well as the entire decision context can
> be determined (locally or via attribute assertion) including any actions
> occurring outside of the XACML/authz concern.
> So they make a request under treatment-->deny.
> They decide that the situation is significant enough to override and
> reassert under BTG-->

and again they are denied.

This is because not everyone is allowed to BTG. By returning a BTG 
response to the first request of those subjects who are privileged 
enough, we tell them that they are allowed to BTG is they deem it to be 
a serious enough situation. This is the model already employed by XACML.

Why does the XACML PDP return Indeterminate with a request for more 
attributes? Why not let the subject simply guess that this is what is 
needed, and let the subject try a bunch of additional attributes just in 
case he can get access with some of them?

I therefore suggest that returning a BTG response is entirely consistent 
with the current XACML model



If their privileges are adequate under this pou
> then the decision can be made--Allow.
> Regards, Mike Davis, CISSP
> Department of Veterans Affairs
> VHA Office of Health Information
> Security Architect
> 760-632-0294
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
> Sent: Wednesday, April 27, 2011 8:06 AM
> To: xacml@lists.oasis-open.org
> 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
> regards
> David
>    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]