[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parametersand alternatives
+1 for the rationale on why these
parameters are not assertions.|
However, to take care of the kind of inconsistencies as raised by this issue, would it make sense to also add the following to the proposed change for Section 2:
"If an intersected policy resulting from union of policy alternatives contains mutually contradictory options for a consumer, the provider MAY choose NOT to include such parameters in the final policy to be advertised, and use default values for them wherever applicable"
So the policy resulting from the alternatives given below may not explicitly contain an sp:IncludeToken parameter, and that may translate to always including this token in message exchanges.
Marc Goodner wrote:
4D23423BBBF19E4188569D67B844381C67DED7EC05@NA-EXMSG-C105.redmond.corp.microsoft.com" type="cite">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; email@example.com 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 uni on 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; firstname.lastname@example.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 venuAll the best, Ashok ------------------------------------------------------------------------ *From:* Aditya Athalye [mailto:email@example.com] *Sent:* Wednesday, May 30, 2007 6:25 AM *To:* K.Venugopal@Sun.COM *Cc:* firstname.lastname@example.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: email@example.com <mailto:firstname.lastname@example.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