Authentication with basicHttpBinding

I have converted my webservice to wcf 开发者_如何学Pythonservice keeping the extension of wcf service as asmx since I have a large client base and do not want to ask users to change the extension. Currently I have username / pwd authentication for my clients which I want them to move out of. Since my user base calls my web service from all sorts of machines and OS's, I am not able to get what type of authentication I can move them to.

X509 Certificate, issued tokens, username pwd or something else..? Any help or guidance with some sample code blocks or urls' would be appreciated.

If you are replacing ASMX service with WCF service you are using BasicHttpBinding (and perhaps also AspNetCompatibility). In that case you don't have many choices. You can use Transport security (HTTPS) with client certificates or TransportWithMessageSecurity (HTTPS + UserName token profile). If you don't want to use HTTPS and you still want to use UserName token profile you need .NET 4.0 and you have to create custom binding like:

<customBinding>
  <binding name="InsecureCredentials">
    <security mode="UserNameOverTransport" allowInsecureTransport="true" />
    <textMessageEncoding messageVersion="Soap11" />
    <httpTransport />
  </binding>
</customBinding>

Ultimately, it depends on whose doing the calling for to your service, IMO.

If this is primarily B-to-B, meaning that your clients are some automated process rather than, say, a silverlight app, I'd prefer identity certs (i.e. x509). If this is a user-driven call such as a silverlight app, then I'd stick with username/password, but consider federated identity.

That said, given the fact that you have many different types of clients, even if it's b-to-b there's no guarantee you'll be able to service every client with x509. In my experience, too many shops just aren't flexible enough to adopt "newer" standards (even though x509 has been around a long time, it's still "new" to a lot of people making web service calls). Therefore, it might be best for you to stick with username/password.

You could offer all three, however. WCF is very very nice that way; it's quite simple to set up a single service implementation that just happens support either username/password auth or x509 or federated identity. Almost all of that is handled by the binding configuration; you might need some plugin code for the username/password auth (depending on how you're set up) but the auth code is completely divorced from the service code.