[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Draft BTG Profile
David, all-- Why not model "BTG=yes" as an environmental variable, which is maintained as a resource (i.e., database) with appropriate access control (like "anyone in the hospital" or "a designated fire marshall or alternate") on updating it? This would toss the whole thing outside XACML, and make it just one of a very large set of specific scenarios in which the PDP has to query an external (environmental) state (like "currentThreatLevel") maintained somewhere "in the cloud." Martin Martin F. Smith Director, National Security Systems US Department of Homeland Security NAC 19-204-47 (202) 447-3743 desk (202) 441-9731 mobile (800) 417-6930 page -----Original Message----- From: xacml-return-2280-martin.smith=dhs.gov@lists.oasis-open.org [mailto:xacml-return-2280-martin.smith=dhs.gov@lists.oasis-open.org] On Behalf Of David Chadwick Sent: Monday, November 29, 2010 7:21 AM To: Rich.Levinson Cc: Ludwig Seitz; xacml Subject: Re: [xacml] Draft BTG Profile Hi Rich On 28/11/2010 20:41, Rich.Levinson wrote: > Hi David and Ludwig, et al, > > I have been following this discussion and it seems to simply revolve around > Policy definitions that Deny access under a given set of conditions, and state information. It is important to bear in mind which element is updating the BTG state (or attribute). If the PDP understands that BTG is a special attribute (or state variable) then it can act in a special way when it is mentioned. If the PDP does not understand BTG then no changes are needed to the XACML specification (scenario iii) below). There are 3 scenarios, namely 1) PDP understands BTG and keeps the BTG state ii) PDP understands BTG but does not keep the state iii) PDP does not understand BTG I believe that your description below is addressing scenario ii) only (correct me if I am wrong) but > will > Permit access if there is that given set of conditions PLUS there is a BTG > indicator that can be checked and if its value is "glass-has-been-broken" > (BTG = true), then access is permitted: > > * (given-conditions = true) AND (BTG = false) then Deny > o + send back BTG as reason for Deny, and indicating > obligations PEP has to tell user reason for denial and > options user has to get access Rather I would say that these obligations are future obligations that the PEP must enforce if the user decides to BTG. If the user does not BTG, then no obligation enforcement is necessary. But if the user does BTG, then the state has to be changed by the PEP, and it is the changing of the state that requires these obligations to be enforced. If they cannot be enforced the state should not be changed. E.g. If the obligation says to log this and email the manager, and the PEP is not able to do this, then the glass should not be broken, since no-one can be informed about it and the user will not have any explaining to do later. (Note that in our design we have the concept of Fallback obligations which are to be performed if the primary obligations cannot be, in order to try to address this issue, but this is a second level issue to the current problem.) > * (given-conditions = true) AND (BTG = true ) then Permit > o + send back BTG indicating obligations PEP must enforce > when in BTG = true state This is a very interesting take on the scenario. What you are suggesting here is that the BTG obligations should only be enforced when the user actually exits the hotel through the firedoor. What I am suggesting above is that the obligations are enforced when the user breaks the glass, regardless of whether he decides to subsequently exit the hotel or not. This is an interesting conceptual point that should be discussed further, because clearly it effects which obligations should be enforced when. It also effects how many times the obligations are enforced. In your scenario they are enforced for everyone who subsequently leaves the hotel by the firedoor, in my scenario they are only enforced on the person who breaks the glass. This again is an interesting conceptual point. If I exit a hotel via an open fire door, should I have to explain this later to someone. If I view a patient record, which is for say a VIP and someone has previously broken the glass for me, should I have to explain this later. If I break the glass on a VIP record but I do not actually view the record, should I have to explain this later to someone? > > I agree it wouild be useful to have a profile describing how to implement > this using standard XACML PolicySets, which, it seems to me can be > done in some fairly straight-forward manners using designated URIs for > AttributeIds and ObligationIds, the semantics of which can be implemented > by the PIPs and PEPs. > > For example, if there is a special AttributeId = "...btg", and a trusted > Issuer of this attribute, then the Policy can look for it within the > context > of the request. > Similarly, a Deny response could use a profile-specific status-code or > just some designated ObligationId to indicate there are > AttributeAssignments > with AttributeId URIs indicating what the PEP is supposed to do. > > Bottom line is I would want to understand what cannot be done w XACML > 2.0 with > a guiding profile using Attributes and Obligations, before defining > alternate means, which > might eventually prove to have needlessly added complexity to the specs. > > Currently, the XACML 2.0 spec indicates that a PEP should only make > specific decisions > if it understands any Obligations that are returned with the decision, > so it seems to me that > a trusted Attribute with the BTG state plus a set of appropriate > Obligations should be > sufficient for this use case. You are most probably correct. The reason I proposed Consequences in our draft instead of Obligations, was that they were future obligations on a subsequent action rather than the current one, whereas with your model above there is no need for future actions since you perform the obligations each time the user accesses the resource and not when the user breaks the glass. regards david > > Thanks, > Rich > > > David Chadwick wrote: >> Hi Ludwig >> >> On 26/11/2010 08:32, Ludwig Seitz wrote: >>> On Thu, 2010-11-25 at 17:05 +0000, David Chadwick wrote: >>>> Hi Ludwig >>>> >>>> The model you have appears to be that each user must BTG himself, and >>>> then he is given the BTG attribute after agreeing to this. But this is >>>> not the model we have, and it is not the model of BTG in general >>>> (e.g. a >>>> fire door in a hotel). >>> >>> You claim your model represents the model of BTG in general. Can you >>> support these claims? >> >> Yes in so far as it has been implemented and we have not yet come >> across any BTG requirement that it cannot satisfy. So in that respect >> it is as general as the HL7 model (which is not a universal standard >> either) >> >> >>> >>> In a previous mail Mike Davis seems to suggest your model is different >>> from HL7's requirements, and currently the requirements from HL7 are as >>> close as it gets for "a model of BTG in general". >>> >>>> Our model is state based, ie. there is a BTG state that is initially >>>> false (corresponding to unbroken glass) and can be set to true >>>> (corresponding to broken glass) by a defined class of user in the >>>> policy. >>>> >>>> Another class of user (typically a manager) can reset the state to >>>> false >>>> (ie repair the glass). >>> >>> I see no difference between a BTG state and a BTG attribute. Could you >>> please explain where you see a difference? >> >> Clearly none if the attribute holds the state! >> But in your attribute model you did not say how the attribute value >> was set to different values. This was added in our model. >> >> >>> >>>> this model is much more general and flexible since it can be applied to >>>> individuals (as in your case) or to roles (e.g. doctors) or to any >>>> combination of attribute holding subjects. >>>> >>>> Furthermore the glass state >>>> can be applied to a single resource or a group of resources. To a >>>> single >>>> action or a group of actions. You can find details in last years ACSAC >>>> conference >>>> >>> >>> I'm all in favor of a flexible BTG model, but from what you present here >>> I fail to see how that cannot be done within the current XACML (v3) core >>> standard. >> >> This is not the issue. The issue is, can we have a standard defined >> way of doing it. You suggest using Advice to signal BTG, so I say we >> should have a profile to standardise the contents of the BTG Advice. >> But I also request a standard way of doing it in XACMLv2 as well, and >> Advice cannot do that. >> >> >>> There is absolutely no requirement for a BTG attribute to be associated >>> with a specific subject or resource. What this comes down to, is a >>> question of attribute management, and that's outside the scope of XACML. >> >> Actually it is in a twilight world, since you have PIPs which manage >> attributes, but you dont describe how they work. So you sort of >> acknowledge that attribute management is needed, but then dont say how >> to do it. What we are wanting to do, is for a specific type of access >> control - BTG - is allow the XACML infrastructure (context handler, >> PIPs, obligation service etc) to manage the BTG attribute/state so >> that applications dont need to. But in order to do this we need to >> standardise more of the protocol between the PEP and the XACML >> infrastructure so that BTG can be handled by the infrastructure, >> thereby reducing the load on applications. >> >>> (note that I think BTG profile should nevertheless give recommendations >>> about how to do that). >>> >> >> which is what we tried to do in a general way in the draft profile. >> >> >>> My point remains: You seem to derive the necessity to make changes to >>> the core standard from your BTG model. I am not convinced they are >>> necessary to realize your BTG model. >> >> Clearly no changes are needed to XACML if you dump all the work on the >> PEP and the application. This is the status quo today. What we would >> like to achieve is that the application independent code can take some >> of the burden off the PEP. This is the motivation for the profile. >> >>> >>> There is a more important problem though: Before coming up with >>> solutions for BTG, we need a good definition of what the requirements >>> for BTG really are. Right now we are starting with a solution and are >>> trying to make the requirements fit, and that seems like a bad approach >>> to me. >> >> If you care to read our ACSAC paper you will find a set of requirement >> there which were derived from the hospital. So we started with a set >> of requirements and derived an application independent way of >> satisfying them. >> >> regards >> >> David >> >>> >>> /Ludwig >>> >>> >>> >> -- ***************************************************************** 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 ***************************************************************** --------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]