Its not explicitly cross domain sessions that I am looking for, but its the easiest way to explain what it is I want.
I have a system which creates websites.
The websites are hosted across lots of different servers.
Users can create their account and then they can create lots of websites.
They could create
http://www.mysite.com
subdomain.mysite.com
and create lots of different sites.
Some times, sites will be COMPLETELY different from one another, however some times, the sites will in fact be so closely linked, that they should probably be considered the same site.
For example:
(Different domain entirely)
mysite-news.com
mysite-blog.com
or (Same domain, different subdomain)
news.mysite.com
blog.mysite.com
What I need is a way for users where they want, to create a federation of sort, which allows by clicking a check box, that they want to allow cross site logins. I cannot change configs unless its a permanent change and won’t affect other sites, because 1000s of sites will be affected.
What do you think would be the best way to support this?
OpenID, SSO?
I need something which is simple for sites to create a ‘federation’ and then allow their sign ins to be cross domain. If someone wants to join then they can.
OpenID provides some nice features, but unfortunately, the cross-domain behavior you’re looking for isn’t something that you’ll find in a standard OpenID implementation. One of the primary design principles of OpenID is that the provider not disclose any information about the user without their explicit consent*, and so any reputable OpenID provider will never tell mysite-news.com that you’ve already logged in to mysite-blog.com without asking for user approval.
[In technical terms, what’s happening here is that mysite-news.com and mysite-blog.com are, conceptually, in the same security “realm”, but OpenID identifies realms by URL patterns, and since they’re on different domains they don’t match.]
And that doesn’t give you the user experience you want. There are some previous answers that do a fine job of outlining the kind of system you need here:
In short, you’ll be setting some sort of auth service on login.mysite.com to answer queries from mysite-news.com and mysite-blog.com. There are still a few ways you can take advantage of OpenID within this.
The redirect-to-login-and-return-a-signed-token flow described there is exactly what OpenID does. So you could still use an OpenID implementation to do all that managing of signed tokens and replay protection, your client sites just get to skip the initial “discovery” part of OpenID and always redirect users to the login.mysite.com provider. And login.mysite.com gets to skip the step of “do I trust mysite-blog.com”, because it’s a special-purpose provider that can have its own whitelist of sites it always works with. OpenID would be purely behind-the-scenes here, users would never know that OpenID was somehow involved.
login.mysite.com could, in turn, use OpenID to ask users to authenticate against their OpenID provider (whether it be Google or Yahoo or a specialist like myOpenID). From there it would look like a standard OpenID login and you’d get all the benefits, the disadvantage is that your login-redirect chain gets a little longer (and correspondingly slower). Them’s the breaks.
Good luck. This is a question that comes up fairly frequently, and I’ve yet to find a really great reference implementation that I can point people to, so if you find something good do come back and let us know.
Lastly, obligatory link to Matasano Chargen’s screenplay on the subject.
[*] the recent Google Buzz fiasco is a good reminder of what happens when you surprise users about who their information is being shared with.