实现“真正的”单点登录：OpenID、其他东西还是自定义黑客？

Posted 2023-03-08

【中文标题】实现“真正的”单点登录：OpenID、其他东西还是自定义黑客？

【英文标题】：Implementing "true" Single Sign-On: OpenID, something else, or custom hack?

【发布时间】：2012-07-23 17:05:24

【问题描述】：

我们正在尝试评估一种解决方案，以便为多个（已经存在的）网络解决方案实施“真正的”SSO。真正的 SSO 在这里意味着登录任何服务，并在所有服务上进行身份验证，而无需用户采取进一步行动。

我们将使用的所有应用程序都支持 OpenID 和/或具有允许 OpenID 的插件，因此这似乎是值得研究的事情。但是，据我了解 OpenID，用户仍需要在每项服务中输入其 OpenID 凭据。

一旦 OpenID 提供者对用户进行了身份验证，是否有一种明智的方法来实现具有自动登录的 SSO？

在早期的项目中，我们在两个应用程序（都在同一个域和服务器上运行）的登录过程中破解了 php 会话数据，因此第一个应用程序中的登录也会为另一个应用程序创建会话数据。但是，这是一个非常老套的解决方案，并且在更新任一应用程序时都容易崩溃，因此我们这次尝试避免它。

还有其他我们可以研究的 SSO 解决方案吗？

【问题讨论】：

这个更适合security.stackechange.com ;)

【参考方案1】：

我假设您可以控制 SSO 实施

您可以做一些事情来确保一旦用户被 SSO 应用程序识别，他将几乎自动登录到您的其他应用程序

在您的 SSO 应用程序中，创建服务提供商白名单。来自这些网站的身份验证请求将被自动批准。因此，不会要求用户手动批准请求 在您的应用程序中，将return_to 参数设置为用户打算立即打开的页面。不要简单地将 return_to 设置为该应用程序主页

顺便说一句，最标准的 openid 实现接受任何 url。但是，如果您想在受控环境中使用 sso，您可以将服务提供者设置为具有受信任身份提供者的白名单。毕竟是服务商发起了openid认证。

【参考方案2】：

是的，有办法做到这一点。运行基于节点的应用程序服务器，并注册跨域技术以提供 cookie 凭据（在每个新用户到达时由站点握手支持，以更好地扩展并最小化每个会话的资源支出）。

我现在正在研究这样一个野兽，我已经完成了 5/6。

我已经预先处理了几个烦人的变量 - 包括确保唯一用户登录的方法 - 我已经对其他问题采取了立场 - 无法在一个系统中完成所有事情。但是，如果一个人愿意停下来，就可以拥有一个真正的 SSO。您的站点将定义您的解决方案。如果您没有准确地描述您的局限性，那么这里就没有可以提供实施的解决方案，而且您的问题的本质是完全实施而不是理论。理论上，您有 4-5 种不同的选择。在实践中，您会找到答案。