您是在集成现有的应用程序，还是只想支持自己的应用程序？
您是在寻找实际的 SSO 还是只是共享凭证？SSO 正在登录单个应用程序，并将该凭据传播到另一个应用程序（例如登录到 Gmail 并自动登录到 Blogger）。共享凭证是您可以跨应用程序使用相同的登录名和密码，但凭证本身不会自动传播。
LDAP 是用于管理共享凭证的通用系统。许多系统允许您将其身份验证存储指向现有的 LDAP 服务器。
例如，如果您在 Java EE 容器中部署了多个应用程序，并且还部署了一个电子邮件服务器和基于 Web 的电子邮件客户端，那么所有这些不同的应用程序都可以指向同一个 LDAP 服务器，并且您的用户将只有一次登录所有不同系统的密码和密码，都用不同的语言编写，都部署在不同的机器上。这是 LDAP 的一个基本用例，几乎每个系统都可以开箱即用地处理这个问题。Glassfish 和 Tomcat 都可以轻松地针对 LDAP 服务器进行验证。Apache（Web 服务器）、Postgres（数据库）、Postfix（电子邮件）等也可以。
因此，如果您只想要一个共享凭证，您现在可以通过安装 LDAP 服务器“免费”获得它。LDAP 与 DBMS 之类的东西有点不同，但是一旦您稍微研究一下并“掌握”它，它就会非常好。OpenLDAP 是一种流行的 LDAP 服务器，但我偏爱 ApacheDS。
在 Java EE 容器中设置它的方法是设置一个“领域”。GF 和 Tomcat 都有开箱即用的 LDAP 领域，我想其余的都可以。但关键是您需要使用 Java EE 安全性来利用 Realm。
看，Java EE 领域的细节是它是容器的一个方面，而不是应用程序。就像连接池是您的应用程序利用的容器资源一样。大多数人都希望安全成为他们应用程序的一部分，他们觉得他们可以更好地控制它。
这一切都很好，直到您开始获得一堆不同的应用程序并且每个人的配置都不同并且拥有单独的用户列表和密码策略等。
LDAP 可以解决很多问题，因为您将它们全部配置为使用相同的凭据存储。
Realm 满足了 Java EE 服务器上的需求。您的应用程序配置为使用容器提供的领域。如果您有多个应用程序和一个 Realm，那么它们都可以在该 Realm 内共享凭据（无论 Realm 类型如何）。
领域可以是任何东西：基于文件、基于数据库、LDAP 等。如果容器集群，领域也可以集群（这很方便）。
Java EE 安全性的阴暗面，以及为什么大多数应用程序都避免它的原因是，由于领域是容器的一部分，而不是应用程序的一部分，它使用起来可能有点笨拙，并且可能无法提供您所需要的功能比如在用户管理、密码策略等方面。
但是 Java EE 安全性的好处在于，一旦您在它的保护伞下，您就可以轻松地在代码中利用整个证书。一个人登录到网站，该证书可以在 Web 应用程序中使用，或者自动传播回 EJB 层（永远是远程 EJB 层），并且信息总是很方便。
您可以将您的 Web 应用程序指向一个领域、您的 EJB、您的 Web 服务。他们都利用相同的部分。
为了获得两全其美的效果，就是利用容器特定的机制来访问容器的安全性。这是 Java EE 安全性的另一面。
诸如 Realms 和直接访问容器安全性之类的东西不能跨容器移植。GF 与 Tomcat 不同，它与 WebLogic 不同。这一切都非常接近，但在细节上有所不同，因此您的代码不会无缝移植。
好的一面是内部应用程序，大多数人只是利用他们拥有的容器，围绕依赖于容器的代码进行合理的抽象，并指出是的，如果他们移动到不同的地方，他们将不得不移植这个容器。但是，在实践中。就像数据库一样，一旦选择了容器平台，人们往往会紧紧依偎并坚持下去。
最后，Servlet 3.0（在 GF3 和 Tomcat 7 中）标准化了更多的编程登录问题，以使它们在容器之间更具可移植性，但基本概念是相同的。
现在，SSO。
SSO 是一个不同的野兽。但是，一开始，GF 和 Tomcat 都支持 Web 应用程序的 SSO。这使您可以登录到一个 Web 应用程序，并且无需登录即可轻松访问其他应用程序。但是 SSO 有点受限，因为它更多地依赖于容器安全性及其生命周期，而不是在应用程序控制下的更灵活的安全性。请注意，不仅在领域（这是给定的）上，而且在基于实际容器的 FORM 登录上，而不是在自定义编程登录上。FORM 登录并不引人注意，但它很实用，而且很有效。实现一个 Realm，将您的应用程序部署到 Tomcat 或 GF 的单个实例（或 GF 3.1 中的集群），您就可以免费获得 SSO，所以如果这很重要，那真的很好。它的可用性对于后台应用程序来说很好，但可能不适用于公共互联网。
如果您想要更复杂的 SSO 解决方案，那么您需要查看自定义实现。OpenSSO 就是其中之一，它依赖于 SAML 和 SAML Web 配置文件。但是，还有其他人。还有 CAS、Atlassian Cloud、Kerberos 和 OAuth。这些都使用与 SAML 不同的协议。如果您想坚持使用 SAML，您还可以查看 Shibboleth，甚至 SimpleSAML（SimpleSAML 是一个 PHP 服务器，可充当 SAML 身份提供者等，但您仍然需要在应用程序中使用服务提供者）。
无论您选择哪种协议，过程基本相同（详细说明此处-跨域登录-如何在从一个域转移到另一个域时自动登录用户）。
但魔鬼在细节中。而且，男孩，有魔鬼吗？
所有这些系统都很复杂。SSO 很复杂。例如，既然您有单点登录，那么单点注销呢？单次超时怎么办？用户登录时凭据更改会怎样？您的 Web 服务的 STS（安全令牌服务）怎么样？（STS 为 Web 服务提供了类似的委托身份验证机制。）
SAML 向您介绍了大量新词汇和大量配置。由于文档不是很出色，并且在很大程度上依赖于标准文档，这些文档与更高级别的通用事物而不是针对您和您的应用程序，因此不容易被采纳。
如果您不需要真正需要 SSO，那么您可能会满足于中央 LDAP 存储之类的东西并从那里继续。
综上所述，作为示例，我们的应用程序同时支持 DB 和 LDAP 后端。他们使用 Glassfish 和 Java EE 安全性。我们完全控制用户体验。我们还通过 SAML 支持 SSO（我们编写了自己的身份和服务提供者），并且使用我们的代码和第三方代码，我们在 Java 和其他应用程序中通过 LDAP 和 SSO 共享凭证。好的一面是这都是基于标准的。不利的一面是标准是用英语传达的，而英语需要解释。
我这么说只是说可以做到。我还使用简单的 Servlet 过滤器编写了临时的、餐巾纸 SSO 实现的背面，包括同域和跨域（同域很简单，共享 cookie）。密码策略、密码恢复、保持活动计时器、多窗口超时和会话管理（这很麻烦）、角色、权限等。到过那里，做到了。
另外，如果我没有提到 Spring 和 Spring Security，它们在 Spring 之上提供了所有这些，我将是失职的。我没有使用它（我不是 Spring 人），但那些人确实知道他们在做什么，所以值得一看。