[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. Thanks Aditya 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; 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 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; ws-sx@lists.oasis-open.org Subject: Re: [ws-sx] Issue i134: InlcudeToken Policy Assertion Parameters and alternatives Ashok Malhotra wrote: |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]