How to get the base64 signature encoding for a WCF

Question

I have a WCF client proxy and am using the following binding element to sign the request to a third party Java web service:

Dim asec As TransportSecurityBindingElement = SecurityBindingElement.CreateCertificateOverTransportBindingElement()
asec.EnableUnsecuredResponse = True
asec.SetKeyDerivation(False)
asec.AllowInsecureTransport = True
asec.IncludeTimestamp = True

However, I'm told there is a validation error on the service side:

Signature validation failed: Invalid encoding type (only base64 is supported) for token:uuid-168b7c90-2d6a-4928-9979-94cb84443d3b-1

So I'm assuming I need to set something (probably the signature?) to base64 encoding. How can I do this?

Answer 1

Setting the MessageSecurityVersion to WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10 seemed to solve the problem:

Dim asec As TransportSecurityBindingElement = SecurityBindingElement.CreateCertificateOverTransportBindingElement(ServiceModel.MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10)

Though I don't know why this works, or what it means.

Answer 2

To answer the question in your answer:

Though I don't know why this works, or what it means.

SecurityBindingElement.CreateCertificateOverTransportBindingElement() initializes the MessageSecurityVersion of the binding to its defaults, which is:

WS-Security 1.1, WS-Trust of February 2005, WS-SecureConversation of February 2005 and WS-SecurityPolicy 1.1.

With the overload you're now calling, you're specifying this:

Basic Security Profile 1.0 based on WS-Security 1.0, WS-Trust of February 2005, WS-SecureConversation of February 2005 and WS-SecurityPolicy 1.1 security specifications.

To determine what EncodingType WCF actually emits, you'll have to either put an HTTP monitor in between (e.g. Fiddler) or let .NET output trace information to log the message being sent. You can also access or request the server logs to see why the server thinks the message is invalid.

I suspect however, given certain web searches on the actual error message, that the Java server complains about your WCF client omitting the EncodingType=...#Base64Binary on the wsse:BinarySecurityToken. According to the spec, that is the only allowed value (or a custom one if both parties agree on it) and it's not marked as optional.

After changing the MessageSecurityVersion to WS-sec 1.0 as also explained here (which is easy to find - once you know what you're looking for), I guess WCF explicitly outputs the EncodingType attribute, causing the service to accept the message.