Cross Domain Single Selective Entry

Question

These are not the explicit gateway sessions I'm looking for, but this is the easiest way to explain what I want.

I have a system that creates sites. Websites are hosted on different servers.

Users can create their own account, and then they can create many websites. They could create

www.mysite.com subdomain.mysite.com and create many different sites.

In some cases, the sites will be completely different from each other, but in some cases, the sites will be so closely connected that they should probably be considered the same site.

For example: (completely different domain) mysite-news.com mysite-blog.com or (same domain, different subobject) news.mysite.com blog.mysite.com

I need a way for users where they want to create a sort federation that allows, by clicking the checkbox, to allow them to enter the cross-site site. I can’t change the configuration if its constant change does not affect other sites, because 1000 sites will be affected.

What do you think is the best way to support this? OpenID, SSO?

I need something that is just for sites to create a "federation", and then allow their inputs to be a cross domain. If someone wants to join, then they can.

Answer 1

OpenID provides some useful features, but unfortunately the cross-domain behavior you are looking for is not what you find in the standard OpenID implementation. One of the basic principles of OpenID development is that the provider does not disclose any information about the user without their explicit consent *, and therefore any reputable OpenID provider will never tell mysite-news.com that you are already logged into mysite-blog.com, requesting user approval.

[Technically, what's going on here is that mysite-news.com and mysite-blog.com are conceptually in the same security area, but OpenID identifies spheres by URL patterns, and since they include different domains they do not match.]

And it does not give you user convenience. There are some previous answers that do a great job of describing the system you need:

• Cross domain login [...]
• A transparent user session on multiple sites [...]

In short, you will install some kind of auth service on login.mysite.com to answer queries from mysite-news.com and mysite-blog.com. There are several more ways that you can use OpenID in this.

• The redirect-to-login-and-return-a-signed-token stream describes what OpenID does. Thus, you can still use the OpenID implementation to perform all operations with signed tokens and anti-replay protection, your client sites will simply skip the initial "open" part of OpenID and always redirect users to the login.mysite.com provider. And login.mysite.com gets to skip the “trust mysite-blog.com” step because it is a specialized provider that can have its own white list of sites that it always works with. OpenID would be entirely off-screen, users will never know that OpenID is somehow involved.

• login.mysite.com may, in turn, use OpenID to ask users to authenticate against their OpenID provider (be it Google or Yahoo or a specialist such as myOpenID). From there, it will look like a standard OpenID identifier, and you will get all the advantages, the disadvantage is that your input redirection chain gets a little longer (and therefore slower). Their breaks.

Good luck. This is a question that arises quite often, and I still have to find a really excellent reference implementation that I can point people to, so if you find something good, come back and let us know.

Finally, a mandatory reference to the Matasano Chargen script on the topic .

[*] The recent Google Buzz fiasco is a good reminder of what happens when you surprise users with whom their information is shared.

Answer 2

SSO is just a concept / state ... This is what you are trying to achieve.

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

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

Google has introduced a hybrid protocol, OpenID and oAuth, which they are trying to use as a standard authentication method. Google provides an integrated login solution in much the same way as you mentioned.

From my interpretation of what you mentioned, is that you mean a solution that the user can simply check the field in their settings to subscribe wherever their account is supported ... This is contrary to the principles, and OpenID. I do not know the current solution, which is really worth something.

Basically, what is being done now, instead of connecting to each site individually using the single sign-on provided by OpenID ... You go to the site with your OpenID account, you are redirected to the oAuth authorization request. This will then allow the oAuth server to authenticate you to this site in the future until the permission is revoked until you authenticate your OpenID account with this oAuth service.

Answer 3

Do you think either openId or SSO is suitable.

See my post on July 29, 2008, 12:50 at 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.

FROM.

Answer 4

As @ keturn explained, OpenID does not allow implicit trust without tricking the system, so I would not recommend it for this particular problem. Instead, I would look at Shibboleth - Single-Sign-On, designed for decentralized architecture.

Assume that master.example.com is linked to child.example.com, so master.example.com provides login functions for child.example.com. A user with a registered login on master.example.com would now like to access the http://child.example.com/resource, which is only a member. Now, Shibolet kicks:

• Authentication: Does the user have a security token?
  • If the user already has a security token from master.example.com, it is checked for validity, and the process continues in step 2.
  • If the user does not have a valid token, he is sent to the login site, for example. http://master.example.com/login. After logging in, the user is redirected to step 1.
• Authorization (optional): master.example.com can allow or deny access to a specific resource on child.example.com by providing additional information (for example, a specific forum on child.example.com is available only to participants in the master.example.com award. Information about the status of a user’s user is visible only on master.example.com, so he must allow or deny access).

Shibboleth implementations are available in many services, such as apache2 or at the application level, as in php (for example, SimpleSAML ).