[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Any kind of policies in a request
I consider the defining features of XACML to be: 1) the architecture consisting of PDP, PAP, PIP, PEP; 2) the policy language; and 3) the request/response language. If you admit non-XACML policies originating from outside the PAP, you practically eliminate the first two features. What does "XACML conformance" mean for such a system? A vendor could offer a "XACML" system that only handled XACML requests and responses, but the interoperability would be very limited. There may be benefits from such a system (or constraints that force it upon you), but the benefits (or motivations) are different than those for a XACML system. If the seat of authority for policies is no longer the PAP, how do you survey the policy space to audit rules or analyze their effect? How do you control the attribute vocabulary? How do you specify and implement policy combining algorithms? These may not be a concern in some implementations, but they are concerns that make XACML (as currently defined) a good choice for many enterprises. I'm not in favor of this proposal, mainly because of the confusion it would cause around "XACML conformance". I suppose you could define a narrow conformance profile simply for XACML request/response, but I don't see the market for that capability. Regards, --Paul > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Tuesday, December 08, 2009 10:11 > To: Rich.Levinson > Cc: Harold Lockhart; Erik Rissanen; xacml > Subject: Re: [xacml] Any kind of policies in a request > > Hi Rich > > Rich.Levinson wrote: > > Hi David, > > > > If this is the case, then the course I would recommend is > to specify > > what is missing from XACML that is required to meet the > requirements > > for those use cases, and then that can be considered as an > enhancement. > > the requirement, put simply, is for the PEP to be able to > pass any type of authz policy along with an authz decision > request to the entity (I am not calling it a PDP for now, see > below) that will process it and return an authz decision to the PEP. > > From the PEP's perspective it is a PDP that can dynamically > be given different policies for different decision requests. > The PEP does not need to know what policy language the PDP > supports. It should not need to care about this (since the > PEP does not create the policies nor process them). However, > the PEP does need to know how to construct a decision request > and process a decision response, and so in order to be > standards conforming the PEP should use the XACML > request/response format (though it could use a proprietary > format and let the entity sort this out but then the PEP > would need to change every time the PDP changes). > > Different people might want to give this entity different > names depending upon what it actually does (just a decision > engine (PDP), a decision engine that can process parameters > as well (PDP+context handler), a decision engine plus > parameter processor plus attribute fetcher (PDP+context > handler+PIP) etc. I did not want to murky the waters by > looking at the internals of this entity. How it is structured > internally is in many respects transparent to the PEP (and > the PEP should not need to care about this). > > So the requirement is for the PEP to be able to pass any type > of authz policy along with an authz decision request to the > PDP/entity that will return an authz decision. > > > > > > In general, my opinion is that XACML should be regarded as an > > abstraction, which is intended to be a superset of all > possible authz > > policies. > > > > However, as you indicate there always will be some "next > requirement", > > and there should be mechanism to carry the policies in a parallel > > channel to the xacml policies, which will enable them to be > delivered > > to non-xacml PDPs that are capable of receiving and processing them. > > > Yes I am happy with this. It solves the requirement mentioned above. > > > > > > The original proposal I saw was in this email that was discussed at > > the TC meeting a few weeks ago: > > http://lists.oasis-open.org/archives/xacml/200911/msg00023.html > > > > which proposed an extension to PolicySet, which would effectively > > intermingle xacml and non-xacml policies within PolicySets, > which is > > what I think people were saying was not desirable. > > > This was due to my research group not being tuned into the > workings of the XACML TC, and proposing what they saw as the > best way of solving the requirement. (Since we were passing a > policy we thought the policy construct was the best place to > put it.) But we are happy for the TC to recommend "the best" > way of doing this to us. The bottom line is that we want to > be standards conformant in what we do, hence we are bringing > the issue to the TC for discussion and resolution. > > (we did this a few years ago when we started to process > obligations and asked the TC how to handle before, with and > after type of obligations). > > > > > As Hal has suggested, adding the capability to the > SAML/XACML decision > > request protocol, possibly allowing non-xacml policies in > > xacml-saml:ReferencePolicies, would address this requirement. > > http://lists.oasis-open.org/archives/xacml/200912/msg00053.html > > The decision request is a perfectly fine solution for us > > thanks > > David > > > > > > Thanks, > > Rich > > > > > > David Chadwick wrote: > >> Hi Rich > >> > >> Rich.Levinson wrote: > >>> Hi David, > >>> > >>> Here are my 4 answers to the questions: > >>> > >>> i) there should be a general mechanism for querying > any remote PDP > >>> for an authz response Y/N > >>> > >>> Y, but xacml req/rsp syntax must be mapped to > local syntax of > >>> non-xacml PDPs > >> > >> obviously. This is what we do already. > >> > >>> > >>> > >>> ii) there is a need to dynamically push a policy to a > remote PDP > >>> along with an authz decision request Y/N > >>> > >>> Y, but the policy is a xacml policy and if the > remote PDP is > >>> non-xacml then there must be a mechanism to map the xacml > >>> policies on arrival to the syntactic reqts of the > non-xacml > >>> PDP > >> > >> > >> Unfortunately this is not possible since XACML is not a > superset of > >> all possible authz policies. It XACML were a superset then > you could > >> map from XACML into anything else. But how do you encode a > Separation > >> of Duties policy into XACML? How do you encode a behavioural trust > >> policy into XACML? > >> > >> > >>> > >>> > >>> iii) the v2 XACML request/response context can be > used as a general > >>> purpose mechanism for making an authz query to any > ABAC PDP Y/N > >>> > >>> Y, but someone must provide a means to map from the XACML > >>> request/response context to the specific ABAC PDP syntax. > >> > >> agreed. We already do this in our PDP context handler. > >> > >>> > >>> > >>> iv) the SAMLv2 profile of XACML can be used as a > general purpose > >>> mechanism for pushing a policy to a remote PDP along > with making an > >>> authz query Y/N > >>> > >>> Y, but the policies must be XACML policies and if > the PDPs are > >>> not XACML PDPs then a mechanism must be provided > to map from the > >>> XACML to the non-XACML syntax. > >> > >> again this wont work for the reasons explained above. > >> > >> (To use an analogy, its a bit like saying that in the 1980s, SMTP > >> should have been used to carry all the X.400 features and then map > >> from SMTP into X.400. Clearly it was not possible, which > is why MIME > >> was invented). > >> > >> > >>> > >>> The rationale behind all these answers is that the > purpose of this > >>> TC is to define a standard for authorization policies and provide > >>> guidance for developing bindings and provide some > bindings to this > >>> standard. > >> > >> understood > >> > >>> > >>> So, if the issue is that there are non-XACML policies > that need to > >>> transmitted in the SAML 2.0 Profile of XACML, my > recommendation is > >>> that a binding be developed that specifies how to map these > >>> non-xacml policies to and from XACML Policy format. That way any > >>> policy, xacml or non-xacml, should be able to be sent to any PDP > >>> using the SAML 2.0 Profile as is. > >> > >> Unfortunately your assumption is that any authz policy can > be written > >> in XACML, and I dont think that is the case (e.g. why was XACMLv3 > >> developed, because you knew there were policies that could not be > >> expressed in v2, such as delegation. I believe this is > still the case > >> for XACMLv3). > >> > >> > >> regards > >> > >> David > >> > >> > >>> > >>> Thanks, > >>> Rich > >>> > >>> > >>> David Chadwick wrote: > >>>> Hi Hal > >>>> > >>>> Yes indeed this was my original proposal, but the group > seemed to > >>>> have some resistance to this encoding, so it was switched to > >>>> putting it into the SAML-XACML request message. > >>>> > >>>> When deciding about topics such as this, I think it is best to > >>>> first agree on the concept, and only then to agree about > the actual > >>>> syntax to be used since several different syntaxes can > be used to > >>>> carry the same conceptual entity. > >>>> > >>>> I am not sure how many people in the XACML group have > agreed to the > >>>> concept and therefore will disagree with any syntax changes that > >>>> are proposed, and how many have agreed to the concept but not to > >>>> the syntax. > >>>> > >>>> I would therefore like to see if we can first get a > broad consensus > >>>> on the concept and only then decide which syntax is the most > >>>> appropriate one to carry new policies to PDP. > >>>> > >>>> So the I should like to ask the group if there is broad > consensus > >>>> that a PEP should be able to dynamically send a policy > to its PDP > >>>> along with an authz decision request, and if anyone disagrees to > >>>> say why they disagree. > >>>> > >>>> In a previous message I asked Anil 4 questions about this issue, > >>>> but now I would like to open this up to the whole group > to ask if > >>>> everyone could answer these 4 questions privately, and if anyone > >>>> answers No to any of them to give their rationale to the > group. We > >>>> can then debate the concept and resolve this issue first before > >>>> proceeding to any syntax encoding details. > >>>> > >>>> i) there should be a general mechanism for querying any > remote PDP > >>>> for an authz response Y/N > >>>> > >>>> ii) there is a need to dynamically push a policy to a remote PDP > >>>> along with an authz decision request Y/N > >>>> > >>>> iii) the v2 XACML request/response context can be used > as a general > >>>> purpose mechanism for making an authz query to any ABAC PDP Y/N > >>>> > >>>> iv) the SAMLv2 profile of XACML can be used as a general purpose > >>>> mechanism for pushing a policy to a remote PDP along > with making an > >>>> authz query Y/N > >>>> > >>>> regards > >>>> > >>>> David > >>>> > >>>> Harold Lockhart wrote: > >>>>> David, > >>>>> > >>>>> When we discussed this in Luxembourg, I assumed you intended to > >>>>> add an ANY to the decision request in the SAML Profile, > not to the > >>>>> definition of XACML policies. > >>>>> > >>>>> I was struck how both you and Prateek have said to me, the wire > >>>>> protocol decision request is the most important part of XACML > >>>>> because it allows a PDP of any kind to be called. It > seems to me > >>>>> logically this is the place where additional > information, such as > >>>>> more policies might be needed by a non-XACML PDP. > >>>>> > >>>>> My main concern is to make it clear that what ever is used here > >>>>> should be profiled and a PDP receiving a request with > contents it > >>>>> does not understand MUST return Indeterminate with some > >>>>> appropriate error code. > >>>>> > >>>>> Hal > >>>>> > >>>>> -----Original Message----- From: Erik Rissanen > >>>>> [mailto:erik@axiomatics.com] Sent: Monday, November 23, > 2009 7:12 > >>>>> AM To: David Chadwick Cc: Rich Levinson; xacml Subject: [xacml] > >>>>> Any kind of policies in a request > >>>>> > >>>>> > >>>>> David, > >>>>> > >>>>> I have been thinking more about this. > >>>>> > >>>>> I think that an extension point to plug in any kind of policy > >>>>> format does not belong in the XACML core schema, and > thus not in > >>>>> the <Request>. The XACML schema is for defining the XACML > >>>>> language, and we would lose some of the benefits of > >>>>> standardization by allowing any content in it. > >>>>> > >>>>> However, SAML defined in the past a protocol for AuthZ > >>>>> query/response. It is my understanding, and please > correct me if I > >>>>> am wrong, that there was an agreement between the SAML > and XACML > >>>>> TCs that the XACML request schema would supersede the > SAML AuthZ > >>>>> formats, and SAML dropped their own. The original SAML protocol > >>>>> was ambiguous regarding the policy language. > >>>>> > >>>>> If we think of the XACML SAML profile to carry the > legacy of the > >>>>> original SAML AuthZ protocol, than I guess it would > make sense to > >>>>> support other policy languages since the original > protocol was not > >>>>> XACML specific. > >>>>> > >>>>> What do the rest of the TC see as the scope of the XACML SAML > >>>>> profile? Is it just about supporting XACML, or does it have a > >>>>> wider scope? > >>>>> > >>>>> Best regards, Erik > >>>>> > >>>>> David Chadwick wrote: > >>>>>> Subsequent to the minutes > >>>>>> > >>>>>> Rich.Levinson wrote: > >>>>>> > >>>>>>> Proposed schema change for policies and discussion from David > >>>>>>> Chadwick and response from Erik: > >>>>>>> > http://lists.oasis-open.org/archives/xacml/200911/msg00023.html > >>>>>>> > >>>>>>> Erik: David proposed req ctx schema for ext pts xml > any, where > >>>>>>> can put proprietary policy lang things; doesn't make sense to > >>>>>>> std on any policies in fmt; suggest using saml/xacml > mechanism Rich: > >>>>>>> sees it as potentially disruptive, effectively > allowing elements > >>>>>>> as children of PolicySet Bill: proprietary elements > don't make > >>>>>>> sense; need further info to be considered; > >>>>>>> > >>>>>>> defer topic until more info from David addressing concerns in > >>>>>>> email and minutes > >>>>>>> > >>>>>> It makes sense because we cannot assume that every PDP > talks the > >>>>>> XACML policy language. However, it is possible to make > every PDP > >>>>>> talk the XACML request/response context. Once we have sticky > >>>>>> policies and obligations which we pass around a distributed > >>>>>> system we need to be able to cater for multiple policy > languages. > >>>>>> If you see my presentation at W3C yesterday at > >>>>>> > >>>>>> http://www.w3.org/2009/policy-ws/slides/Chadwick.pdf > >>>>>> > >>>>>> and look at slide 5 from 11, you will see why we need to relax > >>>>>> the schema requirements on the policy element in the > SAML-XACML > >>>>>> profile, otherwise we have no standard way of passing a sticky > >>>>>> policy to an AIPEP or Master PDP. > >>>>>> > >>>>>> regards > >>>>>> > >>>>>> David > >>>>>> > >>>> > >>> > >> > >> ***************************************************************** > >> David W. Chadwick, BSc PhD > >> Professor of Information Systems Security The Computing > Laboratory, > >> 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 > > > > > ***************************************************************** > David W. Chadwick, BSc PhD > Professor of Information Systems Security The Computing > Laboratory, 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_workgr oups.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]