1

我一直在围绕 StackOverflow 和 Google 寻找 SSO [单点登录] 解决方案。这个概念非常简单，就像“一旦登录，无处不在”

现在我的问题是，由于有许多不同的框架，我们真的需要这样的框架还是我们可以基于基本概念实现简单的 SSO 解决方案，或者在这种情况下我们可以选择什么？

两种情况：

  1. 互联网，我们通过互联网向广泛的人/客户公开我们的 Web 应用程序，在那里我们可以拥有多个域、多个服务器。

  2. Intranet，我们通过 Intranet/Internet 向有限范围的人公开 Web 应用程序。一个更好的例子可能是组织内员工的 SSO

我在撒谎寻找解决方案的案例。

我想为我组织的员工实施 SSO，他们可以登录一次，他们将自动登录所有其他应用程序，如 [邮件/聊天等]。

我们主要使用 LDAP 进行用户凭证管理。话虽如此，现在每个应用程序都可以通过针对 LDAP 验证用户来登录并继续。

或者

我们可以有一个 Web 应用程序，它将与 LDAP 通信以登录并作为 SSO 与其他与之通信的应用程序一起工作。

我在这里做了两个选择。

  1. 使用其中一个框架 [OpenAM/JOSSO 或任何其他框架，如果它足够好并且足以满足我的要求]，它使用我自己的身份验证 [我自己的 jar，它采用用户名和密码并返回授权与否]

  2. 使用我自己的 Web 应用程序，如我所说，它使用我自己的身份验证并持有公钥/私钥机制 [OpenPGP]，并与其他应用程序和 cookie 管理来回通信。

哪个选项更适合我的要求，或者在哪种情况下我们可以选择哪个框架的概述？

4

1 回答 1

2

构建自己的实现是一个糟糕的选择，至少有两个原因：

  • 其他人无法轻松与您的 SSO 提供商集成
  • 你不能确定你的协议没有隐藏的问题

另一方面，选择内置框架并不像听起来那么重要。最重要的是选择一个完善的协议，举三个例子：OAuth2、SAML2 和 WS-Federation。

在这三者之间选择一个协议会让你做出决定：要么选择一个现有的协议实现，要么编写一个自定义的实现。第一个选项当然更容易维护和更安全，只有在您 100% 确定现有实现不能满足您的要求时才创建自​​定义实现。

所有提到的 sso 协议都是通过将您环境中的一个特定应用程序作为身份提供者来工作的。IdP 知道在哪里可以找到用户后台存储以及如何验证凭据以及其他应用程序信任身份提供者。协议之间的区别在于信任关系是如何实现的。简而言之，对 oauth2 的信任在于应用程序服务器和身份提供者服务器之间的直接调用，而 ws-federation 和 saml 在于传递一个数字签名的 xml，一个表示用户是谁以及他/她拥有什么角色的令牌.

于 2013-08-16T16:32:11.613 回答