2

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?

Mr Shoubs
  • 14,629
  • 17
  • 68
  • 107

2 Answers2

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.

Mr Shoubs
  • 14,629
  • 17
  • 68
  • 107
1

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.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • 1
    Thanks. A lot of this is knowing what to look for and unfortunately I was given very little information from the owners of the service, also being new to this part of WCF, it seems to be hard to know what to look for. It's been a long road getting here (4 other questions): http://stackoverflow.com/q/20349062/198048 http://stackoverflow.com/q/19704629/198048 http://stackoverflow.com/q/19431827/198048 http://stackoverflow.com/q/19427768/198048 – Mr Shoubs Dec 05 '13 at 17:24
  • @MrShoubs good questions, nice research and thumbs up for the self-answers! (Not literally, or it would be considered serial-upvoting.) Too bad they didn't get that much attention. Interoperability is challenging sometimes. :) – CodeCaster Dec 05 '13 at 17:48
  • hopefully my answers will help anyone else who has similar problems. Though I guess with interoperability, there are so many factors involved that make every situation fairly unique. – Mr Shoubs Dec 06 '13 at 13:12