views:

742

answers:

5

What's the best way to implement authentication over WCF?

I'd prefer to not use WS-* as it needs to be transport independant.

Should I "roll my own"? Is there any guidance for doing that (articles/blog posts)?
Or is there some way to (and should I) use the built in ASP.NET Membership and Profile providers on the server side?

A: 

Why should WS-* be transport dependant?

The whole point of the WS-* specifications is that they are part of the message, and hence transport independent.

samjudson
A: 

WS-* is transport independant. That's the entire point.

Authentication really depends on who the desired consumers of your service are. Don't weigh down internal services with security that isn't required, and likewise it's useful to add extra layers of security if you need to know specific things about third party users.

For external APIs we've gone with WS-* authentication using certificates and then a simple authentication mechanism (username and password is supplied, GUID authentication token is returned, token is supplied with all requests after the fact).

DavidWhitney
A: 

Thanks for your answers.

I did not mean transport dependant, my mistake. I meant that I'd like the consumer to be able to choose which endpoint to bind to. And since basicHttpBinding and netTcpBinding, amongst others, don't suppport WS-* I need to use something at the at the service level.

Davids simple authentication is what I've been trying to avoid. Ideally I'd like a way to accomplish the same thing without having to add a token argument to all my operation contracts.

tgmdbm
+1  A: 

Message based authentication, which is WS-Security based, is what you're looking for and is definitely supported by basicHttpBinding and netTcpBinding. I think you are making the mistaken assumption that only WsHttpBinding will support WS-Security, which is inaccurate.

The WS bindings are for WS-* elements other than WS-Security, such as WS-ReliableMessaging. Setting up transport independent message security is still going to be tricky, if you want it to stay secure. For the transports that aren't duplex you'll need to have at least one certificate exchanged in advance.

That might be the other reason you believe message security isn't supported by basicHttpBinding. basicHttpBinding will not allow you to use UserName authentication without transport security (for good reason too I'll add). And since transport security is inherently transport dependent I'm guessing you're trying to avoid it.

So anyhow, if you want to be fully transport independent the first thing you need to tackle is getting the certificates in order and figuring out how you're going to distribute the first (root) certificate(s), or securely exchange certificates. If you have the luxury of an application where you can distribute a master certificate, then take that route. If you're in a more complex scenario than that, you need to step back and think about how hard this problem really is.

nedruod
A: 

If you are exposing an external service that requires user level authentication / authorization, I would recommend using the ASP.NET provider.

There's a useful utility here that allows remote administration of the ASP.NET provider. The ASP.NET solution does require SQL...

Scott P