OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

*****************************************************************


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]