How do I create a network of sites that understand single sign-on?

Question

I have several sites (Asp.Net) that I would like to have a single sign on for...

I would like a user to visit Site1 and have Site1 contact a central single sign-on server (SSS).

The SSS would then determine that the user was not logged on (Not sure how) and would redirect the user to a Logon screen (Still on the SSS).

If authenticated, the user would be redirected back to Site1.

Site1 would treat this arrival as new and would likely ask the SSS if the user was logged on. This time the SSS would suggest that the user in question was indeed logged on. And so Site1 could store this fact in it's session for future reference (perhaps with some suitable timeout)

Site1 would contain a link to Site2 which the user might choose to follow.

Arrival at Site2 should trigger an attempt by Site2 to authenticate the user.

How can I identify the user arriving on Site2 as the same user who already visited Site1 and discover that they have already been authenticated in order that they need not have to log in a second time?

Note: The SSS needs to be a private system where I control the account creation. So I'm afraid I can't be relying on external OpenID servers

Update: I am unable to guarantee at this time that Site1, Site2 and SSS would be within the same domain... So I don't think cookies will cut it.

Answer 1

http://www.ja-sig.org/products/cas/

Answer 2

You could try using a shared session state server.

Answer 3

You could use cookies to store and create authentication tickets for users. We've done that several times and it's worked out quite well.

Answer 4

Don't discard OpenID so rapidly - as the site owner, it's up to you to choose which OpenID provider(s) you choose to support. You could choose to run your own OpenID server and only trust it.

Also, remember that OpenID is a system for authentication - how user X proves they are who they say they are.

Here on StackOverflow, they automatically create accounts when someone uses an OpenID to log on - but you don't have to do that. You can have full control over account creation, with an OpenID associated with each account.

Remember too, that (generally) any software you don't have to write and maintain is a good thing.

Answer 5

Do it the same way everyone else does it, pass around DB-generated tokens between sites with GET or POST, then validate those tokens back to a web service that talks to the DB directly.

So user wants in to site 1 (www.domain1.com). Site 1 checks local domain login session/cookie, fails to find any, redirects user to http://logindomain.com/?return=www.domain1.com. If an earlier logindomain cookie exists (from sign-ins to affiliated sites), send it back to site 1. If not, do whatever user auth you require (KERBEROS checks, Forms auth, openID, etc.) to generate a unique token. Store that in the cookie for logindomain, and redirect them back to wherever "return" pointed to, with your token attached: http://www.domain1.com/?token=123456. Once domain1 validates the token against a web service (or the token DB directly), it can set its own local login session/cookie with the user credentials.

So now you're on site 2 (www.domain2.com) and go to log in. You get redirected to logindomain again with the ?return var set, but it doesn't ask you for the password this time - it already has your token in its SSO cookie. You get immediately redirected back to: http://www.domain2.com/?token=123456 (same token as site1 used). Domain2 validates the token again, and lets you in with no password check.

It gets a little more complicated if you're changing the login URL on the fly or trying to make a hybrid AD/Forms Auth monster like I was tasked to build, but this seems to work fine and matches exactly (at a high level) what IBM and MS docs say their proprietary SSO systems do.