[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 Prateek
Prateek Mishra wrote:
> David,
>
> my concern is that use of "any" in schema is a very blunt tool to
> achieve your goals.
agreed. I am happy to sharpen it if you can suggest a construct for this.
Secondly, this puts a large burden on implementors
> that are creating
> SAMLAuthZRequest processors - how does the processor know which policy
> language is being used?
we have already defined a schema for this in our project (see below),
but we are not proposing to standardise this yet. (But we could if
people wanted to).
> 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
this is what I actually did in my schema, I gave it a revised name.
So would you be happy for the SAML2 XAMCL spec to have two statements in
it, the SAMLAuthzRequest and the ExtendedSAMLAuthzRequest which allows
any policy to be included?
If so, I would prefer the first to be called SAMLXACMLAuthzRequest and
the second ExtendedSAMLAuthzRequest so that the name carries the
semantic difference.
> 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.
we have already done this in our project as below, with the following
schema. But we are not proposing to offer this for standardisation yet (
not until we at least get more experimental experience of using it).
<xs:element name="StickyPolicy" type="StickyPolicyType"/>
<xs:complexType name="StickyPolicyType">
<xs:annotation>
<xs:documentation>
The PolicyLanguage specifies the language the policy is
written in.
The PolicyAuthor specifies the person who wrote the policy.
The PolicyContents contains the policy written in the
language specified in PolicyLanguage.
The PolicyType attribute specifies what type of policy this
is. (see defined URIs below).
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="PolicyLanguage" type="xs:anyURI"/>
<xs:element name="PolicyAuthor" type="saml:NameIDType"/>
<xs:element ref="PolicyContents"/>
</xs:sequence>
<xs:attribute name="PolicyType" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="PolicyContents" type="AnyXMLType"/>
<xs:complexType name="AnyXMLType" mixed="true">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"
processContents="lax">
<xs:annotation>
<xs:documentation>
Any xml content is allowed in this element.
</xs:documentation>
</xs:annotation>
</xs:any>
</xs:sequence>
</xs:complexType>
regards
David
>
> - 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
>>>
>>
>
--
-------------------------------------------------------------
The Israeli group Breaking the Silence has just released a collection of
testimonies by Israeli soldiers that took part in the Gaza attack last
December and January. The testimonies expose significant gaps between
the official stances of the Israeli military and events on the ground.
See http://www.shovrimshtika.org/news_item_e.asp?id=30
The Israeli government defies Obama, and continues its settlement expansion
Israel plans to allocate $250 million over the next two years for
settlements
http://www.palestinecampaign.org/index7b.asp?m_id=1&l1_id=4&l2_id=24&Content_ID=698
whilst simultaneously continuing to bulldoze Palestinian homes
http://salsa.democracyinaction.org/o/301/t/9462/campaign.jsp?campaign_KEY=27357
*****************************************************************
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]