Planning common membership provider for different authentication providers

I am trying to implement form based authentication (FBA) membership provider that is able to support multiple authentication mechanisms. Take it as an self-training experiment. In this posting I will introduce bases of my experiment and introduce my current plans and ideas.

Why membership provider for multiple authentication mechanisms?

There are many people in the world who are users of some social network or some open services provider. Today Facebook and Twitter are very popular social networks. Also Google and Microsoft Live services are very popular although they are not social networks. But all mentioned systems provide their own authentication channels also to other applications. The question is: why should I have another username and password if I have already one at some of systems I mentioned before?

Here, in Estonia, we are building local Microsoft community portal with local Microsoft. We analyzed the situation and decided to use Live ID as authentication mechanism in our portal. We were a little it worried too because we were afraid that there are load of users who are not happy with Live ID as authentication mechanism. And guess what – as time has shown us there is no reason to worry! Our ~2000 users (Estonia is small country) are all happy with Live ID and the ones who doesn’t have Live ID yet can go and join Live ID – it’s free.

If you have no idea where I live then take a look at map on right. The small and strong screen splash there is Estonia. If you don’t see it well then feel free to click on this image to see it at original size. :)

Profile store

To give you better idea what I am thinking about take a look at the following diagram.

Every user has one account. Each account has account specific information and custom profile fields. Profile fields can be customized because different sites need different profiles. My profile store will be common enough to live over almost all common situations. Or at least I hope so.

Authentication tokens is the place where I store tokens for users returned by different authentication mechanisms. This way each user is able to use authentication mechanism he or she likes. Also users will be able to use Twitter and Live ID both if they like. Same goes for all the other authentication providers I am able to support.

Implementation details

I have some implementation details on my mind. I am sure that the end result is maybe a little bit different but in big picture things hopefully does not change a lot.

• There will be one common membership provider that is able to authenticate users to ASP.NET site by querying the authentication tokens table.
• It is possible that each authentication provider gets it’s own membership provider that is extended from common one. I am not very sure yet if this is the great idea.
• Usernames will be in form: ProviderName:ProfileName so I am able to detect which authentication mechanism I have to look to find out correct profile.
• There will be additional field for profile or membership provider that returns me ProfileName without authentication mechanism information.
• Data will be held in SQL Server at first place. Later I plan to support also the other databases or data stores.
• There will be common login page that is automatically able to offer authentication mechanisms it knows about.

I think these points are good enough for start.

What’s next?

Well…. as a next thing I try to implement support for different authentication mechanisms and when all common providers are covered then it is time to write generic membership and role providers for ASP.NET. My first four candidates are Twitter, Facebook, Google and Live ID and after these I plan to write providers. Stay tuned, it will be interesting experiment!