Cross Domain Single Selective Sign In_问答_开发者

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 ac开发者_运维技巧count and then they can create lots of websites. They could create

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:

Cross-domain login [...]
Transparent user session over several sites [...]

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.

SSO is merely a concept/state... It is what you are trying to achieve.

OpenID is good for authentication, and it is good for authentication from multiple sites. It does not carry over authentication information from one site to another.

What seems to be the industry standard SSO technology IMO is oAuth. It is used by Facebook, Twitter, Google, etc...

Google has implemented a hybrid protocol of OpenID and oAuth that they are attempting to push as the standard authentication method. Google provides a federated login solution almost exactly as you have mentioned.

From my interpretation as to what you had mentioned is that you have in mind a solution that a user can just check a box in their settings to sign in everywhere their account is supported... This goes against the principles behind both oAuth and OpenID. I do not know of a current solution that is actually worth anything.

Basically what is done now is instead of connecting to each site individually with a single login provided by OpenID... You log in to a site with your OpenID account, you get redirected to the oAuth authorization request. This will then permit the oAuth server to authenticate you on that site in the future until the permission is revoked as long as you are authenticated with your OpenID account with that oAuth service.

As you suggest, either openId or SSO would be suitable.

See my post on 29 July 2008, 12:50 in http://groups.google.co.uk/group/comp.lang.php/browse_thread/thread/b682ed2a8b7fbb3f/f5f27f120e264fa0?hl=en&lnk=gst&q=single+sign+on+symcbean#f5f27f120e264fa0

for an example of how to implement SSO.

As @keturn explained, OpenID does not allow implicit trust without tricking the system, which is why I wouldn't recommend it for this specific problem. Instead, I'd have a look at Shibboleth - a Single-Sign-On intended for a decentralized architecture.

Let's assume the website master.example.com is linked to the website child.example.com, so that master.example.com provides login functionality for child.example.com. A user with a registered login on master.example.com would now like to access a resource http://child.example.com/resource, which is members-only. Now, Shiboleth kicks in:

Authentication: Does the user have a security token?
1. If the user already has a security token from master.example.com, it is checked for validity and the process continues at step 2.
2. If the user does not have a valid token, he is forwarded to a login site, e.g. http://master.example.com/login. After login, the user is forwarded to step 1.
Authorization (optional): master.example.com may allow or disallow access to a specific resource on child.example.com by providing additional information (e.g. a specific forum on child.example.com is only accessible to premium members of master.example.com. The information of the member status of the user is only visible to master.example.com, so he has to allow or deny the access).