Re: [xacml] Any kind of policies in a request

[Anil Saldhana <Anil.Saldhana@redhat.com>]

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