跨域单选登录 [英] 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 account and then they can create lots of websites. They could create
www.mysite.com subdomain.mysite.com 并创建许多不同的网站.
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.
例如: (完全不同的域) mysite-news.com mysite-blog.com 或(同一域，不同子域) news.mysite.com blog.mysite.com
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.
您认为什么是支持此的最佳方法? OpenID，SSO?
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提供了一些不错的功能，但是不幸的是，您要查找的跨域行为不是在标准OpenID实现中会发现的. OpenID的主要设计原则之一是，提供者未经他们的明确同意不会泄露有关用户的任何信息*，因此任何信誉良好的OpenID提供者都不会告诉mysite-news.com您已经登录到mysite-blog .com而无需用户批准.
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.
[从技术上讲，这里发生的事情是，从概念上讲，mysite-news.com和mysite-blog.com在同一安全领域"中，但是OpenID通过URL模式识别领域，并且由于它们处于启用状态他们不匹配的不同域.]
[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 [...]
简而言之，您将在login.mysite.com上设置某种身份验证服务，以回答来自mysite-news.com和mysite-blog.com的查询.您仍然可以通过几种方法来利用OpenID.
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.
-
描述的重定向登录并返回签名令牌的流程正是OpenID所做的.因此，您仍然可以使用OpenID实现来执行对已签名令牌和重播保护的所有管理，您的客户端站点只需跳过OpenID的初始发现"部分，并始终将用户重定向到login.mysite.com提供程序. login.mysite.com可以跳过我信任mysite-blog.com"这一步骤，因为它是一个特殊用途的提供程序，可以拥有自己的白名单，该站点始终与之合作.在这里，OpenID完全是幕后花絮，用户永远不会知道OpenID是以某种方式参与其中的.
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可以使用OpenID来要求用户针对其OpenID提供程序进行身份验证(无论是Google还是Yahoo或像myOpenID这样的专家).从那里看起来像是标准的OpenID登录，您将获得所有好处，缺点是您的登录重定向链会更长一些(并相应地变慢).他们是休息.
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.
最后， [*]最近的Google Buzz惨败提醒我们，当您使用户惊讶于与谁共享其信息时，会发生什么.
[*] the recent Google Buzz fiasco is a good reminder of what happens when you surprise users about who their information is being shared with.
这篇关于跨域单选登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
