[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Any kind of policies in a request
David, my concern is that use of "any" in schema is a very blunt tool to achieve your goals. Secondly, this puts a large burden on implementors that are creating SAMLAuthZRequest processors - how does the processor know which policy language is being used? THere are whole range of messy issues that would need to be resolved. The kind of extension you seek is better achieved by creating a new type - lets call it ExtendedSAMLAuthZRequest - which extends from SAMLAuthZRequest and includes the fields you need. Another alternative would be to completely re-factor the design of SAMLAuthZRequest to accomodate the use of multiple policy languages - you would need some way to represent the identity or name of the policy language in the request so that the processor can reasonably understand the contents of the AuthZRequest and fail appropriately. - prateek > > > Prateek Mishra wrote: >> This seems a very alarming proposal. > > why do you say that? The existing schema already allows any XACML > policy to be provided. All we are doing is relaxing the requirement > that the policy should be in the XACML language. > > >> >> I think its reasonable to allow for extensibility in the schema, its >> quite another think to simply throw in a few any's into the schema > > It might be that any is not the best construct to allow what we > require, ie. a policy in any language, but how else do you suggest we > achieve this extensibility? > > >> because this seems convenient to some project or another. I think >> this would have considerable impact on processors which are expecting >> a SAMLAuthZRequest. > > On the contrary. If the recipient supports this protocol then it is > already expecting to receive new policies for its PDPs. There are many > more PDPs out in the world that dont support the XACML language than > do support it, so the recipient is quite likely to have one or more of > these PDPs along with its XACML one. > > So, if you dont like the proposal I have made, how do you suggest that > a policy in any language can be carried? > > regards > > David > >> >> >> Thanks, >> >> - prateek >>> Hi Anil >>> >>> OK, now I understand your position. But it is opposed to the existing >>> SAMLv2 profile of XACML, since ii) should by Yes to fit the existing >>> profile, and iv) should be yes if the phrase "a general purpose" is >>> removed. In fact the only change I am proposing is to make iv) >>> general purpose as opposed to its current XACML specific purpose. >>> >>> I attach a Word document (sorry for that) which provides a modified >>> schema showing the change I propose highlighted in yellow, which is >>> the addition of one line, namely >>> >>> <xs:element ref="xs:any" minOccurs="0" maxOccurs="unbounded"/> >>> >>> This allows a policy in any language to be sent. >>> >>> I have also changed the name of the type to reflect that it is now >>> general purpose, and also so that it does not clash with the >>> existing type definition. >>> >>> regards >>> >>> David >>> >>> >>> Anil Saldhana wrote: >>>> Hi David, >>>> >>>> On 11/24/2009 04:15 AM, David Chadwick wrote: >>>>> Hi Anil >>>>> >>>>> I dont understand precisely what your objection is. Please could >>>>> you be more specific by answering the following questions >>>>> >>>>> i) there should be a general mechanism for querying any remote PDP >>>>> for an authz response Y/N >>>>> >>>> Y >>>>> ii) there is a need to dynamically push a policy to a remote PDP >>>>> along with an authz decision request Y/N >>>>> >>>> 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 >>>>> >>>> Y >>>>> 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 >>>>> >>>> N >>>> (The policy update has to be outside the normal request mechanism. >>>> If your use case is to make authz decisions based on a new >>>> replacement for a policy that exists just for the duration of the >>>> authz query, then that is interesting but a new use case which may >>>> require new constructs). >>>> >>>>> regards >>>>> >>>>> David >>>>> >>>>> Anil Saldhana wrote: >>>>>> David, >>>>>> I have a hard time really agreeing to your proposal of >>>>>> interlinking requests and xacml policies. >>>>>> >>>>>> The XACML policy aspect has to be out of band wrt the >>>>>> request-response mechanism. >>>>>> >>>>>> Regards, >>>>>> Anil >>>>>> >>>>>> On 11/23/2009 06:12 AM, Erik Rissanen wrote: >>>>>>> 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 >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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 >> >> --------------------------------------------------------------------- >> 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]