[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Draft BTG Profile
Hi Erik Having read Rich's post again, one way of interpreting it is that nothing needs to be done to the XACML standard since it does not need to understand BTG or do anything special for it. It only requires the policy writer to create some application specific obligations that indicate BTG related actions. I agree that this is one way of tackling BTG, and this is what we have already done in our existing implementation (since we had no alternative!). However, this does not make things easy for applications since they need to do all the BTG processing themselves. Our objectives in standardising BTG are two fold: i) to make it very easy for applications to support BTG ii) to make BTG supporting PDPs portable by defining a standard way of supporting BTG. Using a standardised obligation to signal a BTG response would be (part of) the solution for ii) so this could work. Defining a standard BTG action as well would complete ii). We already have the machinery to do i) by using an XACML PDP wrapper regards David On 29/11/2010 13:38, Erik Rissanen wrote: > Hi David, > > There is also the approach suggested by Rich, which might solve it for > you: use obligations. It would mean that the PEPs must understand the > obligation since they cannot ignore it, but it would work in either 2.0 > or 3.0. Would this work for you? > > There is no standard negotiation protocol about XACML v2 vs v3 between > PEP and PDP. > > Best regards, > Erik > > > On 2010-11-29 12:46, David Chadwick wrote: >> Hi Erik >> >> On 29/11/2010 08:58, Erik Rissanen wrote: >>> Ni David, >>> >>> Yes, it is true that XACML 2.0 does not have advice. >>> >>> However, the problem with the BTG-status code is that your proposal does >>> not define in any manner what happens within the PDP to maintain the >>> state of BTG or to perform the calculations to emit the BTG status code. >> >> This is correct. This is because, when Seth was involved in the >> discussions last year, it was not agreed which component should be >> responsible for maintaining the BTG state, and flexibility should be >> maintained here. It could be the PEP, the context handler or PIP (ie. >> some intermediate component between the PEP and PDP), or the PDP. >> Consequently the draft profile was written allowing for all three >> possibilities. >> >> >>> In your proposal the PDP is a black box, >> >> again correct, because we make no assumptions about the policy >> language that is supported by the PDP - the XACML request context is a >> good standard for interfacing to any PDP that supports any policy >> language. >> >> >> and although we would define >>> the status code, there would be no way to write an XACML policy, in >>> either 2.0 or 3.0 to actually emit the code. >> >> This is also correct. Until an XACML PDP is state based I think this >> will continue to be the case. (In our particular implementation we >> maintain the state in the context handler/PIP component, and use the >> existing XACML request context to talk to an XACML PDP, but we need >> the enhanced XACML request context to talk to the PEP). >> >> >>> >>> Would it be problematic for you to use the 3.0 schema and advice? >> >> Theoretically no, we could use this for the request/response context, >> but practically it would mean that our PEPs would need to be enhanced >> to support XACMLv3. The lack of backwards compatibility between V3 and >> V2 request contexts is a problem. Do you have a version negotiation >> mechanism specified for PEPs talking to remote PDPs? Or are they >> supposed to know beforehand which protocol to talk? >> >> regards >> >> David >> >> >> That >>> way your (non XACML I presume) PDP can emit the advice in a proprietary >>> manner, and the 3.0 policy schema can be used to emit the advice by an >>> XACML 3.0 PDP. >>> >>> Best regards, >>> Erik >>> >>> On 2010-11-26 17:41, David Chadwick wrote: >>>> Hi Erik >>>> >>>> Unfortunately this has not answered the fundamental difference - >>>> Advice does not apply to XACMLv2. >>>> >>>> On 26/11/2010 10:26, Erik Rissanen wrote: >>>>> Hi David, >>>>> >>>>> There are a couple differences. Advice has an explicit expression >>>>> syntax >>>>> in the XACML policy schema, so the behavior of it can be controlled in >>>>> the policy. The status code facility is much more limited in the spec. >>>> >>>> But it is sufficient for our needs. So that is OK. You cannot argue >>>> that a single bit is limited if all you need to represent is a boolean. >>>> >>>> >>>>> Only a couple of error codes are defined and there are no standard >>>>> expressions to control how the status detail is constructed. >>>> >>>> we dont require status detail either. >>>> >>>> Plus using a status code provides backwards compatibility for PEPs >>>> that dont understand the new status value. >>>> >>>> So it seems like a perfect vehicle for passing back the new response >>>> type. >>>> >>>> regards >>>> >>>> David >>>> >>>> >>>> The status >>>>> code mechanism was defined before I joined the TC, so I don't know the >>>>> original motivation behind it, but I have always viewed it as a way >>>>> for >>>>> an implementation to signal errors in the processing. It's not >>>>> intended >>>>> to be used as part of normal policy decisioning. That is what >>>>> advice is >>>>> for. >>>>> >>>>> Best regards, >>>>> Erik >>>>> >>>>> >>>>> On 2010-11-25 18:57, David Chadwick wrote: >>>>>> I dont see the difference between standardising a status code in a >>>>>> profile and standardising an Advice in a profile, except for one >>>>>> thing >>>>>> >>>>>> Advice is not available to XACMLv2 implementations >>>>>> >>>>>> regards >>>>>> >>>>>> david >>>>>> >>>>>> >>>>>> >>>>>> On 25/11/2010 15:29, Doron Grinstein wrote: >>>>>>> I agree with Ludwig. An Advice with a standard ID defined in a >>>>>>> profile allows for interoperability. The PEP can enforce that the >>>>>>> caller presents the necessary and expected attributes in order to >>>>>>> perform the BTG. In addition the PEP should LOG the BTG operation so >>>>>>> that an alert can be initiated, auditors will be advised, etc. >>>>>>> >>>>>>> Doron Grinstein CEO BiTKOO >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 25, 2010, at 7:06 AM, "Ludwig Seitz"<ludwig@axiomatics.com> >>>>>>> wrote: >>>>>>> >>>>>>>> On Thu, 2010-11-25 at 14:36 +0000, David Chadwick wrote: >>>>>>>>> Hi Ludwig >>>>>>>>> >>>>>>>>> answers below >>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> I have some questions related to the proposed approach: >>>>>>>>>> >>>>>>>>>> 1.) You propose to introduce a new status code. Why not simply >>>>>>>>>> use Advice instead? It seems a bit superfluous to add new >>>>>>>>>> elements to the standard when there are suitable elements in >>>>>>>>>> the standard already. >>>>>>>>> >>>>>>>>> the whole purpose of standardising the status code is so that >>>>>>>>> different implementations can interwork without having to find >>>>>>>>> out what the status code or Advice element is that is being set >>>>>>>>> by a particular PDP. >>>>>>>>> >>>>>>>> >>>>>>>> Yes but you can achieve the same effect by just standardizing >>>>>>>> Advice-ids in a profile, without adding new elements to the >>>>>>>> XACML-schema and without requiring new behavior. >>>>>>>> >>>>>>>>>> 2.) You propose to introduce a new element >>>>>>>>>> called<Consequences>. Why not use either Advice or Obligation >>>>>>>>>> with AttributeAssignments instead? >>>>>>>>> >>>>>>>>> We have used the syntax of Obligations, because this is what they >>>>>>>>> are. But with one difference. They are future obligations that >>>>>>>>> will come into effect if some future event happens. We did not >>>>>>>>> want to call them obligations, since the semantic of these is >>>>>>>>> quote "An operation specified in a policy or policy set that >>>>>>>>> should be performed by the PEP in conjunction with the >>>>>>>>> enforcement of an authorization decision" >>>>>>>> >>>>>>>> Ok I guess then your approach with the "future obligations" is the >>>>>>>> one I don't see as necessary. >>>>>>>> >>>>>>>> Why not use this procedure: >>>>>>>> >>>>>>>> 1. Return an Advice "user can BTG" with the Deny decision 2. Offer >>>>>>>> the user to perform the BTG action. If the user chooses to do so, a >>>>>>>> new attribute for that user is created. 3. Resubmit the original >>>>>>>> request with the new attribute 4. Other policies matching the BTG >>>>>>>> attribute now permit access (possibly with Obligations requiring >>>>>>>> special auditing). >>>>>>>> >>>>>>>>>> General question: From the document you provided I cannot see >>>>>>>>>> the necessity for introducing new elements into the standard. >>>>>>>>>> Could you try to explain which functionality are you want to >>>>>>>>>> achieve that cannot be realized with the existing features of >>>>>>>>>> the standard? >>>>>>>>> >>>>>>>>> 1. A standard way of specifying this response type. By its very >>>>>>>>> nature it needs to be in the standard. >>>>>>>>> >>>>>>>>> 2. A standard way of indicating future obligations. >>>>>>>> >>>>>>>> I still don't see the necessity for changing the standard to >>>>>>>> implement this use-case. In fact Swedish healthcare implements BTG >>>>>>>> policies using XACML and the approach sketched above. So I'll try >>>>>>>> to clarify my question: >>>>>>>> >>>>>>>> Given the fact that standardizing BTG in a profile is useful, why >>>>>>>> can it not be done without introducing new >>>>>>>> elements/functionality/behavior in the standard? >>>>>>>> >>>>>>>> >>>>>>>> /Ludwig >>>>>>>> >>>>>>>> -- Ludwig Seitz, PhD | Axiomatics AB Training& >>>>>>>> Development | Skeppsbron 40 Phone: +46 (0)760 44 22 91 >>>>>>>> | SE-111 30 Stockholm Mail: ludwig@axiomatics.com | Sweden >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>>> >>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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]