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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parameters andalternatives


What would happen when one alternative has IssuerName and other Issuer.

Regards
Venu


Marc Goodner wrote:
> As I described below, the specification contains the rationale for why these are not defined as assertions. I'm not convinced that we should change that.
>
>
> -----Original Message-----
> From: K.Venugopal@Sun.COM [mailto:K.Venugopal@Sun.COM]
> Sent: Wednesday, June 13, 2007 2:26 PM
> To: Marc Goodner
> Cc: Ashok Malhotra; Aditya Athalye; ws-sx@lists.oasis-open.org
> Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parameters and alternatives
>
> Hello Marc,
>
> Although what you mentioned below is a workable solution, it is
> preferable to depend on the Policy framework, even though it means
> adding a few nested assertions. IMO this is what WS Security Policy spec
> also recommends. Having parameters and then depending on the domain
> specific knowledge for doing a union of the values is less desirable
> than using the default intersection algorithm without extensions.
>
> Regards,
> Venu
>
> Marc Goodner wrote:
>   
>> Venu,
>>
>> I was asked at the last meeting to look into previous discussion relevant to i134. There are ways that SP assertions can be constructed that are less than optimal. Conversation about combinations that don't make sense from Gudge are in these meeting minutes under 27:
>> http://www.oasis-open.org/archives/ws-sx/200603/msg00010.html
>>
>> The text for issue 27 covers the sp:IncludeToken example for i134 this in a way in section 5.1.2 on Token Inclusion. What the text in that section points out is there are combinations that could result in the same token being included multiple times that don't make sense and should be avoided. So it doesn't cover this specific example where there may be a difference in the value of sp:IncludeToken in intersection. The design choice for sp:IncludeToken, as an attribute rather than as an assertion, is described in the specification in Section 11.2:
>> "There are cases where using attributes or child elements as parameters in assertion design is reasonable. Examples include cases when implementations are expected to understand all the values for a given parameter and when encoding the parameter information into the assertion QName would result in an unmanageable number of assertions. A good example is the sp:IncludeToken attribute that appears on the various token assertions. Five possible values are currently specified for the sp:IncludeToken attribute and implementations are expected to understand the meaning of all 5 values. If this information was encoded into the assertion QNames, each existing token assertion would require five variants, one for each Uri value which would result in 45 assertions just for the tokens defined in Section 5."
>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.html#_Toc161826579
>>
>> So for sp:IncludeToken everyone is expected to understand all of the possible values, it does not participate in intersection. So yes, it is possible that a requestor can match a provider policy that has a different behavior here. The requestor can treat this as additional information and chose whether to engage its own behavior or that specified by the provider.
>>
>> Could this be clarified? Yes, I think we issue an errata as follows for section 2 (new text in bold):
>> "It is a goal of the security policy model to leverage the WS-Policy framework's intersection algorithm for selecting policy alternatives and the attachment mechanism for associating policy assertions with web service artifacts.  Consequently, wherever possible, the security policy assertions do not use parameters or attributes. This enables first-level, QName based assertion matching without security domain-specific knowledge to be done at the framework level. The first level matching is intended to provide a narrowed set of policy alternatives that are shared by the two parties attempting to establish a secure communication path. Parameters or attributes defined by this specification represent additional information for engaging behaviors that do not need to participate in matching. When multiple security policy assertions of the same type with parameters or attributes present occur in the same policy alternative the parameters and attributes should be treated as a union unless defined otherwise."
>> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-cs.html#_Toc161826503
>>
>> I've checked and the only other parameters in the spec that this would apply to are sp:Issuer, sp:IssuerName and wst:Claims. This advice is consistent for those as well as sp:IncludeToken so putting it at the top in section 2 makes the most sense to me.
>>     
>
>   
>> -----Original Message-----
>> From: K.Venugopal@Sun.COM [mailto:K.Venugopal@Sun.COM]
>> Sent: Monday, June 11, 2007 4:26 PM
>> To: Ashok Malhotra
>> Cc: Aditya Athalye; ws-sx@lists.oasis-open.org
>> Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parameters and alternatives
>>
>> Ashok Malhotra wrote:
>>
>>     
>>> We should consider changing the assertion to use a nested Policy
>>> rather than a parameter.
>>>
>>> <sp:InitiatorToken >
>>>        <sp:X509Token>
>>>             <wsp:Policy>
>>>                     <sp:IncludeToken ... </sp:IncludeToken>
>>>             </wsp:Policy>
>>>
>>>             <wsp:Policy>
>>>                     <sp:RequireDerivedKeys ... />
>>>                               <sp:RequireKeyIdentifierReference ... />
>>>             </wsp:Policy>
>>>      </sp:X509Token>
>>>    </sp:InitiatorToken >
>>>
>>>
>>>       
>> +1 .
>>
>> Regards
>> venu
>>
>>
>>     
>>> All the best, Ashok
>>>
>>> ------------------------------------------------------------------------
>>>
>>> *From:* Aditya Athalye [mailto:aditya.athalye@oracle.com]
>>> *Sent:* Wednesday, May 30, 2007 6:25 AM
>>> *To:* K.Venugopal@Sun.COM
>>> *Cc:* ws-sx@lists.oasis-open.org
>>> *Subject:* Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion
>>> Parameters and alternatives
>>>
>>> This is one of the classic examples of an inconsistent intersected
>>> policy that we too realized while implementing policy intersection for
>>> policies/policy alternatives/assertions. Of course the use case was to
>>> check for interoperability between 2 different policies each used for
>>> enforcement at the 2 ends of a communication channel.
>>> The default WS-Policy intersection algorithm when applied to security
>>> policies/assertions can result in potentially un-interoperable
>>> policies. The WS-Policy does talk about domain specific comparison
>>> which goes beyond simple QName based comparison, to address this;
>>> which is more pertinent in the security assertions case(Non-security
>>> assertions may not be affected too much IMO). However,
>>> WS-SecurityPolicy does not seem to provide the details on how this
>>> processing should be done to make sure policies resulting out of such
>>> mutually contradictory assertions/policies are still usable as well as
>>> enforceable.
>>> The implementation we did was to do comparison based on assertion
>>> attributes (if any as could be done in the example mentioned below),
>>> or sub-elements/sub-assertions to make sure policies are even
>>> compatible with each other or not, but again it is non-standard, and
>>> can change from vendor to vendor, and could hurt interoperability as well.
>>>
>>> IMO, WS-SecPolicy also needs to provide a standardized mechanism for
>>> intersection/compatibility Out of the Box instead of simply leveraging
>>> WS-Policy intersect algo, something which would then become
>>> vendor-independent.
>>>
>>> Regards
>>> Aditya
>>>
>>> Greg Carpenter wrote:
>>>
>>> Issue i134
>>>
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: K.Venugopal@Sun.COM <mailto:K.Venugopal@Sun.COM> [mailto:K.Venugopal@Sun.COM]
>>>> Sent: Tuesday, May 29, 2007 7:13 AM
>>>> To: ws-sx@lists.oasis-open.org <mailto:ws-sx@lists.oasis-open.org>
>>>> Subject: [ws-sx] New Issue: InlcudeToken Policy Assertion Parameters and
>>>> alternatives
>>>>
>>>> PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL
>>>> THE ISSUE IS ASSIGNED A NUMBER.
>>>> The issues coordinators will notify the list when that has occurred.
>>>> *Protocol:* ws-securitypolicy
>>>> _http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/21362/ws-
>>>> secureconversation-1.3-spec-cs-01.pdf_
>>>>
>>>> _http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws-
>>>> securitypolicy-1.2-spec-cs.pdf_
>>>>
>>>> *Artifact:* spec
>>>> *Type:* spec
>>>> *Title:*  Policy Assertion Parameters and alternatives
>>>> *Description:*
>>>>
>>>> As we know WS Policy does not use Policy Assertion parameters when
>>>> intersecting Policy Assertions. IMO this would impact WS Security Policy
>>>> to certain extent.
>>>> eg:
>>>>
>>>> Alternative A
>>>> -------------------------------
>>>> <sp:AsymmetricBinding >
>>>> <wsp:Policy>
>>>>    <sp:InitiatorToken >
>>>>        <sp:X509Token sp:IncludeToken = ".....Never">
>>>>              <wsp:Policy>
>>>>                     <sp:RequireDerivedKeys ... />
>>>>                               <sp:RequireKeyIdentifierReference ... />
>>>>             </wsp:Policy>
>>>>      </sp:X509Token>
>>>>    </sp:InitiatorToken >
>>>>
>>>>    <sp:RecipientToken >
>>>>        <sp:X509Token sp:IncludeToken = ".......Never">
>>>>              <wsp:Policy>
>>>>                     <sp:RequireDerivedKeys ... />
>>>>                    <sp:RequireKeyIdentifierReference ... />
>>>>             </wsp:Policy>
>>>>      </sp:X509Token>
>>>>    </sp:RecipientToken >
>>>>
>>>> </wsp:Policy>
>>>> </sp:AsymmetricBinding >
>>>>
>>>>
>>>> Alternative B
>>>> -------------------------------
>>>> <sp:AsymmetricBinding >
>>>> <wsp:Policy>
>>>>    <sp:InitiatorToken >
>>>>        <sp:X509Token sp:IncludeToken = "......Always">
>>>>              <wsp:Policy>
>>>>                     <sp:RequireDerivedKeys ... />
>>>>                               <sp:RequireKeyIdentifierReference ... />
>>>>             </wsp:Policy>
>>>>      </sp:X509Token>
>>>>    </sp:InitiatorToken >
>>>>
>>>>    <sp:RecipientToken >
>>>>        <sp:X509Token sp:IncludeToken = "......Always">
>>>>              <wsp:Policy>
>>>>                     <sp:RequireDerivedKeys ... />
>>>>                    <sp:RequireKeyIdentifierReference ... />
>>>>             </wsp:Policy>
>>>>      </sp:X509Token>
>>>>    </sp:RecipientToken >
>>>>
>>>> </wsp:Policy>
>>>> </sp:AsymmetricBinding >
>>>>
>>>>
>>>>
>>>> When intersected with the default algorithm of the policy framework the
>>>> resulting policy would contain mutually contradictory X509Token
>>>> parameters. On one hand, the resulting policy would require never to
>>>> include X509Tokens while at the same time always requiring to include
>>>> X509Tokens. The intersection result would effectively yield an invalid
>>>> policy.
>>>>
>>>>
>>>> Regards,
>>>> Venu
>>>>
>>>>
>>>>         
>>>       
>>     
>
>
>   




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