Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
I have a question. A client I have been doing some work recently has a range of websites with different login mechanisms. He is looking to slowly migrate to a single sign-on mechanism for his websites (all written in asp.net mvc).
I am looking at my options here, so here is a list of requirements:
- It has to be secure (duh)
- It needs to support extra user properties over and above the usual name, address stuff (such as money or credits for a user)
- It has to provide a centralized user management web console for his convenience (I understand that this will be a small project on top of whatever design solution I choose to go for)
- It has to integrate with the existing websites without re-engineering the whole product (I understand that this depends on the current product implementation).
- It has to deal with emailing the user when he registers (in order for him to activate his account)
- It has to deal with activating the user when he clicks the activate me link in the email (I understand that 5 and 6 require some form of email templating system to support different emails per application)
I was thinking of creating a library working together with forms authentication that exposes whatever methods are required (e.g. login, logout, activate, etc. and a small restful service to implement activation from email, registration processing etc.
Taking into account that loads of things have been left out to make this question brief and to the point, does this sound like a good design?
But this looks like a very common problem so arent there any existing projects that I could use?
Thanks for reading.
The basic thing to realize is that you can't authenticate a user using standard Forms Authentication across multiple domains. For example, dev.google.com and www.google.com are different domains and if a user signs into dev.google.com he isn't automatically signed into www.google.com unless Google does something special to enable this. This is because the browser can't access the cookies of another website.
The only way to really make the cross domain sign on work is to include a key value like a session ID in the query string of the URL that the website examines and sets the user's authentication cookie. You can probably do that manually through your site using a small bit of your own custom code.
Example: http://www.example.com/autoLogin.aspx?sessionid=23232323
The danger of this approach though is that someone could spoof a user session by finding out the address that was used by the user and checking the session ID. So you need to make sure what the value used to authenticate the user across domains is time sensative and dynamic. Don't make it the user's user ID or username or something like that.
Now, if the sites are on the same domain you can give them all the same MachineKey and then a user already logged into one site won't be logged out when the move around through the different websites on the same domain.
Look into the ASP.Net Membership Provider model.
Below are a small sample of links to resources on MSDN about this. It should cover all your needs. The last two link is to a sample implementation in SQL. You can easily expand the fields to accomodate your needs.
- Walkthrough: Creating a Web Site with Membership and User Login
- Managing Users by Using Membership
- Sample Membership Provider Implementation
- ASP.Net MVC Membership Starter Kit
Your other option is to implement login with OpenID/Windows Live or similar.
