Authentication with an SOA approach using C#

I am doing a rebuild of a website and I'm trying to use an SOA approach. The current website is in .NET 2.0 and uses the out of the box SqlMembershipProvider.

We're trying to eliminate direct connections to the database and push everything through a WCF service layer. The approach we're using for this is to have everything separated - There's a library for model开发者_运维知识库s and interfaces, a library for the services, and then a library for the service proxies.

The biggest hurdle so far is figuring out how to manage user authentication and their session. What's the best way to do this with this approach.

Should we scrap the .NET membership model and go with something like OpenId, and just allow users to reconnect their data to the new account?

I've done some searching and can't find a lot on how to manage this, though I know it's been done before.

Here's what I ended up doing, in case anyone is interested. I started off using the WCF Authentication Services, but then realized it didn't give me everything I wanted. I could log on and off, but will still have to create my own methods for registration and getting the MembershipUser.

So I went in my ServiceContracts library and create an interface I called IMembership. At first, I created it as a class and inherited from MembershipProvider so that I could get all the method stubs generated for me. Once they were generated I modified the stubs and made it into an interface.

Then I went into my Services Library and created the implementation for the interface which was simple, because for the implementation I just used Membership.Provider....

Then in my Service Provider Clients library, I did the usual implementing of the IMembership interface, also inheriting from ClientBase<>. Right next to it I created a WCFMembershipProvider, which implemented MembershipProvider, and called the methods from the MembershipClient I just created.

In my WebApp that host the WCF Services I set up my SQL Membership provider in the web.config, and then created my svc file and endpoints for the service.

In the consuming web app, I just added the service client reference to the svc, and then set up the Membership Provider for my WCFMembershipProvider.

And viola - I'm in business.

A lot of repetitive code, but it works nice.

The principal problem you will run into when trying to create a WCF service and maintain the equivalent of session state is that there are no cookies (since there is no browser to maintain them), so the .NET membership providers are not going to be terribly helpful by default. I know how I have handled the equivalent issue is to have a generated token (for instance, a Guid) correspond with the state information I need to maintain.

Your question, however, is more about authentication. I don't know that you would be able to make an OpenId implementation work through WCF (though I understand it works great for plain old ASPX). You could use just a simple username/password authentication scheme (possibly using the MembershipProvider manually, if you need it for dealing with the password encryption in the database), and you can pass the username and password through the service using (most likely) Transport security (SSL).

I hope this helps somewhat. Maybe someone has come up with a more standard session-state replacement for WCF, but I'm not aware of it if so.

Hard to provide a specific answer without knowing a little bit more about your desired setup.

Do you plan to expose your WCF service as a public accessible independent of your website? Will your web pages access your WCF service directly via AJAX?

The easiest scenario is probably a strict layered deployment UI talks only to Website, only website talks to WCF Service.

http://msdn.microsoft.com/en-us/library/ms731049.aspx is a good read on using the ASP.NET membership model with WCF.

I built a site that used AJAX to talk to the WCF service layer. We used the forms authentication provider with WCF. It worked fine except that there wasn't a graceful way to handle the login through a web service. In our case that was fine as we wanted to the user to go to the website and login by entering credentials.

If you have already invested in collecting user's credentials to work with SQLMembership provider, you could surface it via ADFS+claims based model. This would work with all 3 of the above scenarios. There is a bit of learning to do though