Which proper WCF binding to use?

1
votes

I have the following criteria to help me pick a WCF Http binding. My services need to:

  1. be deployed in an intranet support impersonation/delegation
  2. be interoperable with clients using unknown technology
  3. support transaction flow between client and servers
  4. not use certificates if possible (discards "Transport" security mode)

We need to decide between basicHttpBinding and wsHttpBinding.

Here are a few notes and questions on the three points:

  1. I believe wsHttpBinding with "Message" security mode and "Windows" clientCredentialType would allow me to perform delegation.
  2. The security configuration selected in point 1. to implement delegation does seem to make interoperability complex to support, am I right? The WS-* standards (wsHttpBinding) are definitely interoperable, but combined with "Message" security and "Windows" credential, could any WS-* compatible client invoke my services?
  3. I believe wsHttpBinding seems the way to go here to support transaction flow?
  4. Using "Message" security without certificates seems simpler in our situation?

Thanks in advance

1
wcfwcf-bindingbasichttpbindingwshttpbinding
See this other SO question on the topic for an answer - marc_s
For internal .NET clients, you could use one endpoint with netTcpBinding - fast, compact, easy to use. For non-.NET clients, you could set up a wsHttpBinding endpoint. One service - two endpoints - one of the powers of WCF! - marc_s

1 Answers

1
votes

If you want to support transaction flow, you need to use the wsHttpBinding. basicHttpBinding is really just that, a basic XML web service. MS claims it supports the WS-I Basic Profile v1.1 but it looks more like v1.2 since you can use MTOM with that binding.

Both are highly interoperable: wsHttpBinding is an implementation of numerous WS-* standards; what it doesn't support are older SOAP-only clients. That includes anyone using a .NET 2.0 style web service reference, and many forms of Java-based SOAP proxy.

With security, you start to get more of the benefits of a wsHttpBinding showing up. The basicHttpBinding cannot do Windows credentials, though, as you noted, that will limit your interoperability. I suspect you will find it very difficult to authentication non-Windows clients using Windows credentials, but as you indicated, that's the only way to get impersonation to happen. For non-WCF clients running on Windows, you may have more luck, since the client could still get access to the logged-in user's authentication token.

The best way to see how your security modes are going to affect non-WCF clients is to publish the bindings for your service and run the Java wsimport tool against them; if that can produce a working proxy from your WSDL then you should be able to use the service from any client.