1

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

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

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

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

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

4

2 回答 2

0

我假设您可以控制 SSO 的实施

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

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

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

于 2012-07-28T19:28:50.863 回答
-1

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

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

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

于 2013-03-26T08:58:16.993 回答