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 the sites are having common look-and-feel and should share the same user base.

And in such extreme case I still want all the sites to transparently (as much as possible) share user sessions with the following key properties:

1. Single sign-on. When user signs on at passport.example.org and visits any other site — he should be treated as logged in.

   Logged in users get “Hello, $username“ greeting in site header and different navigation menu, listing services they have access to. If he's not signed in, instead of greeting there's a “Sign on” link, pointing to passport.example.org/signon.

   The list of trusted domains is known, so this is fairly simple to implement either with OpenID or with some homebrewn lightweight protocol. When user first hits the site, I'm redirecting him to special authentication endpoint at passport.example.org, which then silently redirects him back, with identity information (or “not signed on” anonymous identity) included. For most browsers this is completely transparent. Obviously, I'm using nonce values to fight redirection loops.

2. Single sign-off. When user clicks “sign off” in the header of any site the next time he visits any site — he should be seen as “not sign on”.

   OpenID was not designed for this. My current idea (I already have a partially-working implementation) is to send not user identity, but “global” session token and share global sessions table (global_session_token ↔ user relation) in DB.

3. Robots and cookieless-users support. Sites are having public areas, which should be accessible by user-agents without any cookie support.

   Because of this, redirection I've mentioned in (1) becomes a problem, because for every single page request, I'll end up throwing user-agent to auth endpoint and back. Not only this will confuse robots, but it will pollute my session database with dead-on-birth sessions very quickly. And I definitely don't want to display “hey, you don't have cookies enabled, go away!” page, that'd be extremely rude and disappointing. While I require cookie support to login, I want users to freely read what the sites are for and so on — without any restrictions.

   And I explicitly don't want to put session IDs in URLs except for some transparent cross-domain redirections I've mentioned. I believe doing such is a security problem and just generally a Bad Thing.

   And here I'm almost out of ideas.

Okay, I know this is hard, but Google actually does this somehow with (google.com, google.lot‑of‑gTLDs, gmail.com and so on), right? So this should be possible.

I'd be grateful for either protocol description ideas (that'd be the best) or links to systems (either code to read or just live sites to watch and learn upon) already successfully implementing something like this.

To sum it up: Several domains without common root, shared user base, single sign-on, single sign-off, no cookies required to browse anonymously.

All of the sites are on the same network (but rest on different servers) and partially share the same PostgreSQL database (resting in the different schemes of the same database). Most of sites are written with Python/Django, but some of them are using PHP and Ruby on Rails. While I'm thinking of something framework- and language-agnostic, I'm grateful for pointing to any implementations. Even if I won't be able to use them, if I'll get the idea how it's done there maybe I'll be able to come up implementing something similar.

Answer 1

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.