Question

I’m working on a single sign-on solution for two ASP.NET MVC3 websites. The sites are on separate subdomains. I’m using Forms Authentication and so far I everything is working well. When I sign into a.example.com I’m automatically signed in to b.example.com too. Nice.

Each application has its own database.

My question is this – if I want to keep certain user information in sync between the two sites (say the last activity date or some user preference) then should I have a User table in both databases and somehow keep them in sync or should only a.example.com’s database have a User table and b.example.com somehow reads and writes to it?

Thanks for your advice.

Edit: Thanks to adam I’m leaning towards storing all user data in a separate database. I will pass the authenticated user’s username and ID to each application in the authentication cookie. Can anybody offer any advice around maintaining referential integrity between the two databases?

Answer 1

Most SSO solutions I’ve seen have a central accounts portal where users can maintain settings, change email address etc.

Think Google:

• google.com/reader
• google.com/analytics
• google.com/accounts

This represents a single user store, providing authentication to several sites. This has various benefits, such as a single place to store session hashes and other security details (for preventing things like man-in-the-middle attacks).

In a true SSO, an authentication request redirects to the central auth system (ie google.com/accounts), authenticates and then redirects to the service that requested authentication.

From your description, it sounds like you have separate authentication for each site/service, but the user db is shared.