OpenID的创造性使用 形势

我有三个网站，都曾经是同一个。因此，他们使用单个数据库进行用户管理和身份验证。不幸的是，它们是非常独特的网站，并且已经发展到包含完全不同的功能

当所有三个站点都只是一个站点时，我们使用了一个漂亮的布局切换器，通过键入请求的URL来确定要使用的样式表。但是，如果您使用来自

domain2.com

的用户登录到

domain1.com

，服务器将为您交换URL而不会出现问题

当我们向一个站点添加功能时，我们需要将这三个站点划分为不同的系统，以避免自己陷入困境。在

domain1

中添加一个特性会破坏

domain3

上的一个不相关系统，因此将事情分开是更明智的。但我们保留了相同的用户数据库，因为它与我们的许可和订阅系统相关联

现在，我们想开始使用SSL/TLS来保护站点。。。这意味着它们是通过HTTPS而不是HTTP传输的

使用HTTP，我们在将用户从一个站点版本转移到另一个站点版本时没有太多问题。你可以登录到这三个站点中的任何一个，服务器会检测到你应该在哪个站点上，并将你踢到那里。由于我们使用状态服务器进行会话管理，因此在传输过程中也不会丢失任何内容（相同的用户数据库、相同的会话ID、相同的会话）

使用HTTPS，当我们将用户从一个站点踢到另一个站点时，我们就失去了这一点。目前，我们所能做的就是显示一个弹出窗口，并解释“您打算登录

domain2.com

…请更新您的书签并再次登录”，然后将它们踢到正确的域。这是可行的，但它是一个不雅观的解决方案，让最终用户感到沮丧，而且它真的很草率

理想溶液 理想情况下，用户一旦到达他们要转移到的站点，就会自动登录到该站点。因此：

• 使用

  domain2.com

• 获取一个弹出窗口，解释您的错误并要求您更新书签
• 自动转移到

  domain2.com

  并登录，就好像您刚开始就去了那里一样

原始方法 我们必须完成的第一个想法是重定向用户，并将某种ID附加到URL，并在他们到达新站点时获取适当的GET参数。虽然这是工作，我们可以登录的人。。。这很不安全。您基本上创建了一个令牌，任何人都可以使用它作为该用户进行身份验证，并通过网络将其传递给可以拦截和模拟的用户

OpenID方法 我现在的想法是，使用OpenID的一些变体，我甚至不确定它是否会起作用（这就是问题所在）。

domain1.com

和

domain2.com

都在我们的服务器上，在我们的控制下，并使用我们的SSL证书。我们拥有对数据库的完全访问权限，一旦知道要恢复哪个会话，就可以在站点重定向后将用户重新登录后恢复其会话

当我过去使用OpenID时，它采用以下格式：

转到我要使用的站点A，然后单击“登录”

被重定向到站点B的登录页面，在那里我已经有一个帐户

登录站点B并授予站点A使用我的信息的权限

被重定向到站点A的已验证部分

我希望我们的系统复制该过程的步骤3-4。基本上：

进入

domain1.com

并登录（您已经拥有一个帐户）

阅读有关修复书签的消息，然后单击“确定”以重定向到正确的站点

被重定向到

domain2.com

从目前为止我对OpenID的了解来看，这似乎是可能的。几天来我一直在阅读OpenID和OAuth来解决这个问题。但我能找到的每个解决方案、教程和手册都描述了一个完全充实的OpenID服务器。我们不需要人们使用外部OpenID对我们的系统进行身份验证，我们也不想成为OpenID提供商。我们只想创建一个符合上述描述的解决方案

---

那么，使用OpenID可以实现这一点吗？我们需要充实协议的哪些部分才能使其工作？

您不一定需要OpenID将用户同时登录到多个域。您只需生成一个从domain1.com到domain2.com的“签名重定向”，并将“断言”作为指向domain2.com的url上的参数之一

断言应该包含用户ID、时间戳和使用域1和域2之间的共享秘密生成的签名。为了防止重播攻击，domain2应该验证时间戳是否相对较新（10分钟）。签名应该通过将断言与共享秘密散列生成。签名使domain2能够验证domain1是否生成了断言，前提是共享机密仅在domain1和domain2之间已知

在较高的层次上，我描述的机制相当于在SAML世界中生成“未经请求的断言”。OpenID理论上支持未经请求的断言，但我从未见过它在实践中实现

如果您以前没有实现过这种单点登录（SSO）技术，那么应该非常小心，因为不正确的实现可能会让攻击者以任何用户的身份登录domain2。

类似：