views:

201

answers:

2

Hi all,

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:

  1. It has to be secure (duh)
  2. It needs to support extra user properties over and above the usual name, address stuff (such as money or credits for a user)
  3. 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)
  4. It has to integrate with the existing websites without re-engineering the whole product (I understand that this depends on the current product implementation).
  5. It has to deal with emailing the user when he registers (in order for him to activate his account)
  6. 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.

+2  A: 

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.

Your other option is to implement login with OpenID/Windows Live or similar.

Mikael Svenson
i know the ASP.Net Membership Provider but is it flexible for the scenario i mentioned? like how does it delegate email sending for confirmation etc to the underlying web app?thx
Yannis
E-mailing has to be built on top of the provider. Eg. http://www.c-sharpcorner.com/uploadfile/raj1979/passwordrecovery10032008150514pm/passwordrecovery.aspx has an ASP.Net pw recovery control which does e-mailing.
Mikael Svenson
Added a note about using OpenID or Winodws Live for SSO. Depending on your scenario it could be an option.
Mikael Svenson
Mikael - do you have an example of doing this sort of thing with OpenID? My main problem currently is that the lack of documentation pushes me to create my own solution and be done with it...
Yannis
Also, the password recovery control is not asp.net mvc that is one of my requirements currently.
Yannis
As for OpenID and MVC - SO -http://stackoverflow.com/questions/526890/best-openid-api-for-asp-net-mvc-application And you might end up coding some controllers yourself in order to meet all requirements. Or google for already made ones.
Mikael Svenson
I believe the current version of NerdDinner uses both OpenID and google id.
Dan Vallejo
+2  A: 

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.

Paul Mendoza
We did it via a guid and the database has a "autologin" table with an expiration time of 3 minutes. This is assuming that all the site can access a single shared database.
Dan Vallejo
I used this approach for inspiration and I created a single sign on service that uses tokens to ensure that the request hasn't been tampered with. it doesnt need the machine key since the user is forwarded (either in actual terms or transparently) in a login service and when authenticated successfully returned back to the return url which receives an encrypted token and asks the login service to decrypt it. if successful the user information are stored in the session (or cookies or whatever storing mechanism is used)
Yannis