Interoperability issue for Supporting Tokens references

[glassfishrobot]

Suppose to have a web service with a WSDL that contains a SignedEndorsingSupportingTokens policy like this:

<sp:SignedEndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">

The SOAP message generated by Java client with Metro 1.4 is (only relevant parts of message): urn:uuid:00ef138c-5dcb-499f-a43f-4c2ff1334d3c MIIC1TCCAj6gAwIBAgIESD6KujANBgkqhkiG9w0BAQUFADCBjTELMAkGA1UEBhMCSVQx HzAdBgNVBAoMFlByb2dldHRvIENOSVBBIE1JVCBDTlMxFDASBgNVBAsMC0VOVEVERVNDWCjfd5l5x8xE 01a8BHCJB0CzieC0g9GPDkvHRrDT21pMVxP5pov9FQEfDTprxVvFbymVHqaupgzA0Whb9PYDKi5fsQVi XMFFmXvkK9zgoU 9vJwyTo960ohdmYen0viRJ0gXfo= E09XV4/s5RSEGwFxd+S5dr6M4Ck= The SOAP message generated by C# client with WCF 3.0 is (only relevant parts of message): urn:uuid:cc5a30f3-f1ad-49bd-8612-8b864a593ca5 MIIC1TCCAj6gAwIBAgIESD6KujANBgkqhkiG9w0BAQUFADCBjTELMAkGA1UEBhMCSVQx HzAdBgNVBAoMFlByb2dldHRvIENOSVBBIE1JVCBDTlMxFDASBgNVBAsMC0VOVEVERVNDWCjfd5l5x8xE 01a8BHCJB0CzieC0g9GPDkvHRrDT21pMVxP5pov9FQEfDTprxVvFbymVHqaupgzA0Whb9PYDKi5fsQVi XMFFmXvkK9zgoU ralDKvN2kRSE3YSRpqzzPHnt/7w= JtmRyW2OQ5ya2s/VTSMiDMkiCPE= You can see in both messages that the X509 security token corresponding to SignedEndorsingSupportingTokens policy, is embedded in BinarySecurityToken tag and is ATTACHED in the message. The Signature tag is rather different in the two messages. In particular differs for an additional transform processing in the Metro message, which provides the algorithm [http://docs.oasis-](http://docs.oasis-) open.org/wss/2004/01/oasis-200401-wss- soap-message-security-1.0 # STR- Transform for the extraction(reference) of the token to be signed. This additional transform processing generete an interoperability issue on WCF part: System.Security.Cryptography.CryptographicException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 System.Security.Cryptography.CryptographicException: Unsupported transform or canonicalization algorithm. at System.IdentityModel.StandardTransformFactory.CreateTransform(String transformAlgorithmUri) at System.IdentityModel.TransformChain.ReadFrom(XmlDictionaryReader reader, TransformFactory transformFactory, DictionaryManager dictionaryManager) at System.IdentityModel.Reference.ReadFrom(XmlDictionaryReader reader, TransformFactory transformFactory, DictionaryManager dictionaryManager) at System.IdentityModel.StandardSignedInfo.ReadFrom(XmlDictionaryReader reader, TransformFactory transformFactory, DictionaryManager dictionaryManager) at System.IdentityModel.Signature.ReadFrom(XmlDictionaryReader reader, DictionaryManager dictionaryManager) at System.IdentityModel.SignedXml.ReadFrom(XmlDictionaryReader reader) at System.ServiceModel.Security.WSSecurityOneDotZeroReceiveSecurityHeader.ReadSigna tureCore(XmlDictionaryReader signatureReader) at System.ServiceModel.Security.ReceiveSecurityHeader.ReadSignature (XmlDictionaryReader reader, Int32 position, Byte[] decryptedBuffer) at System.ServiceModel.Security.ReceiveSecurityHeader.ExecuteFullPass (XmlDictionaryReader reader) at System.ServiceModel.Security.StrictModeSecurityHeaderElementInferenceEngine.Exec uteProcessingPasses(ReceiveSecurityHeader securityHeader, XmlDictionaryReader reader) at System.ServiceModel.Security.ReceiveSecurityHeader.Process(TimeSpan timeout) at System.ServiceModel.Security.MessageSecurityProtocol.ProcessSecurityHeader (ReceiveSecurityHeader securityHeader, Message& message, SecurityToken requiredSigningToken, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates) at System.ServiceModel.Security.AcceptorSessionSymmetricMessageSecurityProtocol.Ver ifyIncomingMessageCore(Message& message, String actor, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates) at System.ServiceModel.Security.MessageSecurityProtocol.VerifyIncomingMessage (Message& message, TimeSpan timeout, SecurityProtocolCorrelationState[] correlationStates) If you see the WCF code, you can notice that: internal class StandardTransformFactory : TransformFactory { // Fields private static StandardTransformFactory instance = new StandardTransformFactory (); // Methods protected StandardTransformFactory() { } public override Transform CreateTransform(string transformAlgorithmUri) { if (transformAlgorithmUri != "http://www.w3.org/2001/10/xml-exc-c14n#") { throw DiagnosticUtility.ExceptionUtility.ThrowHelperError(new CryptographicException(SR.GetString("UnsupportedTransformAlgorithm"))); } return new ExclusiveCanonicalizationTransform(); } // Properties internal static StandardTransformFactory Instance { get { return instance; } } } From the code, seems that the only supported transform algoritm is [http://www.w3.org/2001/10/xml-exc-c14n#](http://www.w3.org/2001/10/xml-exc-c14n#). If you see the Metro 1.4 code, you can notice this: package com.sun.xml.ws.security.impl.policyconv; import com.sun.xml.ws.policy.PolicyAssertion; import com.sun.xml.ws.policy.PolicyException; import com.sun.xml.ws.security.impl.policy.PolicyUtil; import com.sun.xml.ws.security.policy.Binding; import com.sun.xml.ws.security.policy.SupportingTokens; import com.sun.xml.ws.security.policy.Token; import com.sun.xml.wss.impl.policy.mls.EncryptionPolicy; import com.sun.xml.wss.impl.policy.mls.SignaturePolicy; import com.sun.xml.wss.impl.policy.mls.SignatureTarget; import com.sun.xml.wss.impl.policy.mls.WSSPolicy; import com.sun.xml.ws.security.policy.SecurityPolicyVersion; /** * * @author K.Venugopal@sun.com */ public class SignedEndorsingSupportingTokensProcessor extends EndorsingSupportingTokensProcessor { /** Creates a new instance of EndorsingSupportingTokensProcessor */ public SignedEndorsingSupportingTokensProcessor(SupportingTokens st,TokenProcessor tokenProcessor,Binding binding, XWSSPolicyContainer container,SignaturePolicy sp,EncryptionPolicy ep,PolicyID pid) { super(st,tokenProcessor,binding,container,sp,ep,pid); } protected void addToPrimarySignature(WSSPolicy policy,Token token) throws PolicyException{ SignatureTarget target = stc.newURISignatureTarget(policy.getUUID()); stc.addTransform(target); SecurityPolicyUtil.setName(target, policy); SecurityPolicyVersion spVersion = SecurityPolicyUtil.getSPVersion ((PolicyAssertion)token); if(!PolicyUtil.isUsernameToken((PolicyAssertion) token, spVersion) && ! PolicyUtil.isSecureConversationToken((PolicyAssertion)token, spVersion)){ stc.addSTRTransform(target); } SignaturePolicy.FeatureBinding spFB = (SignaturePolicy.FeatureBinding) signaturePolicy.getFeatureBinding(); spFB.addTargetBinding(target); } } In Metro there isn't distinction if the token is attecched or not. To make it interoperable, it should be distinguish the two cases and handle them differently instead of using STR-Transform as always. #### Environment Operating System: All Platform: All URL: [http://forums.java.net/jive/thread.jspa?threadID=54664&tstart=0](http://forums.java.net/jive/thread.jspa?threadID=54664&tstart=0) #### Affected Versions [1.4]

[glassfishrobot]

Reported by dloiacono@java.net

[glassfishrobot]

kumarjayanti@java.net said: re-assign.

[glassfishrobot]

kumarjayanti@java.net said: accept issue.

[glassfishrobot]

jdg6688@java.net said: Fixed:

http://forums.java.net/jive/thread.jspa?messageID=324953

[glassfishrobot]

recht@java.net said: This should also be applied to primary tokens, as the same problem exists there (see http://forums.java.net/jive/thread.jspa?messageID=325409)

[glassfishrobot]

mmatula@java.net said: Planning for 1.5.

[glassfishrobot]

jdg6688@java.net said: Fixed for 1.5 and 2.0 for Supporting Tokens as stated.

For primary tokens, a separate issue should be filed.

[glassfishrobot]

Was assigned to kumarjayanti@java.net

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-1066

[glassfishrobot]

Marked as fixed on Wednesday, March 4th 2009, 5:15:21 am