[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
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] Sent: Tuesday, May 29, 2007 7:13 AM To: 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]