views:

82

answers:

2

I am building an application that will have web, windows and mobile (iPhone) client, I want to use WCF to implement the service layer and not being familiar with WCF I am a little confused when it comes to security, authentication and authorization.

What I would typically like is to re-use as much of the ASP.Net membership components as possible to save me time writing that code as it is tedious and repetitive. Is this a good approach and what alternatives are there?

Can anyone give me guidance as to how best achieve what I am looking for?

+1  A: 

If you run WCF in "ASP.NET Compatibility Mode" (it's one attribute in code to allow it and one line of config to enable it), you can use all of the usual ASP.NET security mechanisms with WCF as-is. See http://msdn.microsoft.com/en-us/library/aa702682.aspx

Eugene Osovetsky
+1  A: 

Check out this article series on WCF security scenarios which explains a lot of the best practices you should embrace.

You basically have three choices for securing the messaging between your client and server:

  • nothing
  • transport-level (e.g. protect entire message directly on the protocol level)
  • message-level (e.g. protect/encrypt message per se)

Typically, you would tend to use transport-level (TCP/IP-level) security when you can be sure there's only a single hop between your client and your service, e.g. in a corporate LAN environment behind the firewall. This is the fastest - use netTcpBinding in your corporate (Windows) LAN environment.

If you have potentially multiple hops (e.g. routers, store-and-forward intermediaries etc.) - typically your internet / external clients scenario - then transport-level security won't work anymore, so you probably have to use message-level security to encrypt and sign the message per se, as it travels from the client to the service.

Now this is just about securing the message on its way.

As for authentication (knowing who it is calling you), you can typically use Active Directory / Windows credentials inside your LAN / company, or username/password for external clients (or possibly certificates for the same purpose, although that's a bit more work). You can also imagine allowing anonymous users who don't tell you who they are - or reject them - that's up to you.

Once you know who it is calling you, you can then do authorization - deciding what they can do. Here you'd typically use Active Directory group membership in corporate/LAN scenarios, or the ASP.NET membership / role system in other scenarios. Or you can roll your own - that's totally up to you.

Hope that helps a bit and gets you started for now!

Marc

marc_s