我一直在寻找关于StackOverflow和Google的SSO [单点登录]解决方案。 这个概念非常简单，因为“登录后，无处不在”
现在我的问题是，由于有许多不同的框架， 我们真的需要这样的框架，还是我们可以基于基本概念实现简单的SSO解决方案，或者在哪种情况下我们可以选择
两个案例：
互联网，我们通过互联网公开我们的网络应用程序 广泛的人/客户，我们可以拥有多个域名， 多个服务器。
Intranet，我们公开了Web应用程序 内联网/互联网到有限的人群。一个更好的例子可以 是组织内员工的SSO
我撒谎以寻找解决方案的案例。
我想为我们组织的员工实施SSO 可以登录一次，他们将自动登录所有其他 像[邮件/聊天等...]的应用程序。
我们主要使用LDAP for User 凭证管理。据说，现在每个应用程序都可以 通过验证用户对LDAP进行登录并继续。
或
我们可以有一个 单个Web应用程序，它将与LDAP通信以进行登录和 作为SSO工作，其他应用程序与之交谈。
我在这里做两个选择。
使用其中一个框架[OpenAM / JOSSO或任何其他框架，如果它是好的 并且足够适合我的要求]，它使用我自己的身份验证 [我自己的jar，它使用用户名和密码并返回授权 或不]]
使用我自己的网络应用程序，它使用我自己的身份验证 说并持有公钥/私钥机制[OpenPGP]，和 与其他应用程序和cookie来回通信 管理。
对于我的要求哪个选项要好得多，或者概述在哪种情况下我们可以选择哪个框架？
答案 0 :(得分：2)
至少有两个原因构建自己的实现是一个糟糕的选择：
另一方面，选择内置框架并不像听起来那么重要。最重要的是选择一个完善的协议，命名三：OAuth2，SAML2和WS-Federation。
在这三者之间选择协议会让您做出决定：要么选择现有的协议实现，要么编写自定义协议。第一个选项当然更容易维护和更安全，只有当您100％确定现有实现不满足您的要求时才创建自定义实现。
所有提到的sso协议的工作原理是在您的环境中为身份提供商创建一个特定应用程序。 IdP知道在哪里可以找到用户反向存储以及如何验证凭据和其他应用程序信任身份提供商。协议之间的区别在于如何实现信任关系。简而言之，对oauth2的信任包括应用服务器和身份提供者服务器之间的直接调用，而ws-federation和saml包括传递数字签名的xml，这是一个令牌，表明用户是谁以及他/她有什么角色