Transparent user session over several sites (single sign-on + single sign-off)

Question

I have several sites in different domains: example.com, example.org, mail.example.com and passport.example.org. All of th

Answer 1

I have used shibboleth, for both SSO scenarios and Federated Identity, but I assume you need more simple solutions that the above mentioned.

Answer 2

AFAIK, Google just uses a cookie for the "Google.com" domain. But Google also uses OpenID which allows for a generic login mechanism. Basically, this works by redirecting you to a special login page. This login page will detect if you're logged in or not and if you're not logged in it will ask you to log in. Otherwise, it just redirects you straight to the next page.

So, in your case a user would open somepage.example.com and the session for this app has no login ID. Thus it would redirect the user to logon.example.biz where the user will log in. Behind this page would also be a session and that session would tell that the user is already logged in. (Or not, in which case the user must log in first.) It then redirects the user somepage.example.com?sessionid=something where this sessionid would be stored in the session of somepage.example.com. Then this session will also know that the user has logged on and for the user it would almost seem to be transparent.

In reality, the user is redirected twice.

Answer 3

Well, let me explain a bit further then. (All URLs are fictional!) As I said, the visitor goes to http://www.yourwebpage.com and indicates he wants to log in. He is redirected to http://your.loginpage.org?return=http://www.yourwebpage.com/Authenticated where he will have to provide his username and password.
When his account information is valid, he will return to the page that was provided in the login URL, but with an additional parameter that will be used as ID. Thus, he goes to http://www.yourwebpage.com/Authenticated?ID=SharedSecret where SharedSecret would be a temporary ID, valid for 30 seconds or less.
When your authentication page gets called, the page would then call a method that's shared between yourwebpage.com and loginpage.org to look for the account information of SharedSecret to retrieve a more permanent ID. This permanent ID is stored in the web session of yourwebpage.com and should NEVER be shown to the user.
The shared method could be anything. If both servers are on the same machine, they could just both access the same database. Otherwise, they might communicate with another server through web services. This would be server-to-server communication thus it doesn't matter if the user is a robot or has no cookie support. This part won't be noticed by the user.
The only thing you'll have to deal with is the session for the user. Normally, users will be sent a session ID that's stored in a cookie but it can also be part of the URL as part of a GET request. It's a bit more secure to have the session ID inside a POST request, though, by adding a hidden input field to your form.

Fortunately, several web development languages do already provide session support so you don't even have to worry about maintaining sessions and sending session ID's. The technique is interesting, though. And you need to be aware that sessions should always be temporary since there's a risk that session ID's get hijacked.

If you have to deal with multiple sites on different domains then you will need to work on some server-to-server communication first. The easiest would be by letting them share the same database but it's better to build a web service around this database, for additional protection. Make sure this web service only accepts requests from your own domains just to add even a bit more protection.
When you have server-to-server connections, then the user will be able to switch between your domains and as long as you're passing along a session ID to the new domain, the user will be logged in. If the user is using cookies, it's not very likely that the session gets lost which would require to log in again. Without cookies, there's a chance that the user will have to log in again to get a new cookie if the session ID gets lost between browsing pages. (For example, the visitor goes to visit Google and then goes back to your site. With a cookie, the session could be read from the cookie. Without a cookie the session is lost since Google won't pass the session ID forwards.

Do keep in mind that passing on session ID's between different domains is a security risk. The session ID can be hijacked, thus making it possible for someone else to impersonate your visitor. Therefore, session ID's should be short-lived and obfuscated. But even if a hacker gains access to a session ID, he still won't have full access to the account itself. He won't be able to intercept the server-to-server communication so he can't access the database with your user information, unless he goes to the login page directly.

Answer 4

A cross domain capable rails plugin to do this would be awesome.

I'd like to do it, the only way I could think of was to force the user to download a toolbar, or some little air app that would handle logging in automatically for me.

I'd love to know another way 'cause that blows

Answer 5

For this solution no need passport server.

Signin

1. Login
2. Create token with encrypted session id and other info
3. Show img with token from all you domains for setting cookies on its.

Authorization by cookie

1. You already have cookies on all domains.

Sign out

1. Clear cookie
2. Destroy session
3. Clear relation user id with last session id in DB (I think you save session id in user table for rising up session by cookie)

I'm can't try this solution. But now i have same problem as you (SSO) and i try this tomorrow.

Answer 6

If all your applications are on the one domain, then it is not too difficult because you can use a domain level cookie to handle the session control. (Cookie-less session management is difficult, but can be done, but is difficult.)

However, you indicated some sites on the example.com domain, and some on the example.org domain.

Playing a bit with my google sigh-in, and other sites of theirs orkut.com, it looks like when you hit a page that needs credentials, it redirects you to a common site for account login, which then redirects you back to the original site, presumably passing some sort of session token in the URL. From this, presumably the orkut.com servers confer directly with the google.com servers to verify the token and get whatever other user information is needed.

More Info On Domain Level Cookies as Reqeusted

If you have two sites, say foo.example.com and bar.example.com, you can set a cookie specific to the host, but you can also set a cookie for the domain that will be seen by all hosts on the domain.

So, foo.example.com can set a cookie for foo.example.com specifically, and it will only be seen by itself, but it can also set a cookie for the domain example.com, and when the user goes to bar.example.com they will also see this second cookie.

However, if you also have a site, snafu.example.org, it cannot see this domain level cookie that foo set, because example.org and example.com are two completely different domains.

You can use the domain level cookie to maintain session information across sites in the same domain.

How you set domain level cookies depends on your development environment (I have no experience with rails, sorry).