java - OpenSSO/OpenAM 替代方案

Question

警告!我正在这里钓鱼，我什至不确定我问的问题是否完全有意义。请善待您的回复! :)

最近接手了一个目前基于Java+Linux+Tomcat+MySQL的项目。现在，该系统基本上只是一个网站，在后台有一些 cron 作业来移动一些数据等等。在与产品经理合作开发优先待办事项时，从他想要做的事情中可以清楚地看出我需要开始开发面向服务的体系结构(SOA <-- 流行语警告!)，我最终将混合 Web 服务器和应用程序服务器。注意:我强烈考虑迁移到 Glassfish v3。

目前，身份验证和授权在 Java 代码中处理，用户信息存储在 MySQL 数据库中。至少，在我看来，我需要将其拆分为一个单独的身份验证服务(否则，最终会在整个地方产生一堆重复的代码来处理用户身份验证和授权)。

我一直在研究单点登录 (SSO) 类型的解决方案并进行一些研究。据我所知，OpenSSO 已被 Oracle 正式删除，但被 ForgeRock 选中，现在称为 OpenAM。这似乎非常接近我想要的，但由于我已经有一个基于 MySQL 的系统，我更喜欢有支持它的东西(或某种其他类型的 RDBMS)。我在 Stack Overflow 上发现了这个，它似乎表明它基本上是 LDAP 或什么都没有。

Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?

我的问题是:

OpenSSO/OpenAM 还有哪些其他选择？ LDAP 是要走的路吗？注意:进行“OpenAM vs”谷歌搜索不会产生太多结果。人们是否倾向于“自己动手”？

任何关于这个主题的想法/建议/链接将有助于教育我将不胜感激。预先感谢您的耐心和帮助。

Answer 1

您是在集成现有应用程序，还是只想支持您自己的应用程序？

您是在寻找实际的 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 安全性的阴暗面，以及大多数应用程序避免它的原因是，再一次，由于 Realm 是容器的一部分，而不是应用程序的一部分，因此使用起来可能有点笨拙，并且可能无法提供您想要的功能比如在用户管理、密码策略等方面。

但是 Java EE 安全性的一个优点是，一旦您在它的保护伞下，您就可以轻松地在您的代码中充分利用凭证。一个人登录到该网站，该凭据可以在 Web 应用程序中使用，或自动传播回 EJB 层(永远是远程 EJB 层)，并且信息总是很方便。

您可以将您的 Web 应用程序指向一个领域、您的 EJB、您的 Web 服务。它们都利用相同的部分。

为了获得两全其美的好处，就是利用容器特定的机制来访问容器安全性。这是 Java EE 安全性的另一个阴暗面。

诸如 Realms 和直接访问容器安全性之类的东西不能跨容器移植。 GF 与 Tomcat 不同，与 WebLogic 不同。这一切都非常接近，但在细节上有所不同，因此您的代码无法无缝移植。

好的一面是内部应用程序，大多数人只是利用他们拥有的容器，对依赖于容器的代码进行合理的抽象，并称其为“天”，注意到是的，如果他们移动到不同的地方，他们将不得不移植它容器。但是，在实践中。就像数据库一样，一旦选择了容器平台，人们往往会紧紧依偎并坚持下去。

最后，Servlet 3.0(在 GF3 和 Tomcat 7 中)标准化了更多程序化登录问题，使它们在容器之间更具可移植性，但底层概念是相同的。

现在，单点登录。

SSO 是一个不同的野兽。但是，一开始，GF 和 Tomcat 都支持 Web 应用程序的 SSO。这使您可以登录到一个 Web 应用程序，并且无需登录即可轻松访问其他应用程序。但是 SSO 有一点限制，因为它更依赖于容器安全及其生命周期，而不是在应用程序的控制下更灵活的。请注意，不仅在 Realms(这是给定的)上，而且在基于实际容器的 FORM 登录上，而不是在自定义编程登录上。 FORM 登录并不引人注目，但它很实用，而且很有效。实现一个 Realm，将您的应用程序部署到 Tomcat 或 GF(或 GF 3.1 中的集群)的单个实例，然后您就可以免费获得 SSO，所以如果这很重要，那真的很好。它的可用性适用于后台应用程序，但可能不适用于公共(public)互联网。

如果您想要更复杂的 SSO 解决方案，那么您需要查看自定义实现。 OpenSSO 就是其中之一，它依赖于 SAML 和 SAML Web 配置文件。然而，还有其他的。还有 CAS、Atlassian Cloud、Kerberos 和 OAuth。这些都使用与 SAML 不同的协议(protocol)。如果你想坚持使用 SAML，你也可以看看 Shibboleth，甚至 SimpleSAML(SimpleSAML 是一个 PHP 服务器，它充当 SAML 身份提供者等，但你的应用程序中仍然需要一个服务提供者)。

无论您选择何种协议(protocol)，过程都基本相同(详情请见此处 -- Cross Domain Login - How to login a user automatically when transferred from one domain to another )。

但魔鬼在细节中。而且，男孩，有魔鬼吗？

所有这些系统都很复杂。 SSO 很复杂。例如，现在您有了单点登录，那么单点退出呢？单例超时呢？用户登录时凭据更改会怎样？您的 Web 服务的 STS(安全 token 服务)怎么样？ (STS 为 Web 服务提供了类似的委托(delegate)身份验证机制。)

SAML 向您介绍了大量新词汇和大量配置。它不容易被接受，因为文档不是很好，并且很大程度上依赖于标准文档，这些文档涉及更高级别的通用事物，而不是专门针对您和您的应用程序。

如果您不需要真正需要 SSO，那么您可能会满足于诸如中央 LDAP 存储之类的东西并从那里继续。

综上所述，例如，我们的应用程序同时支持 DB 和 LDAP 后端。他们使用 Glassfish 和 Java EE 安全性。我们完全控制用户体验。我们还通过 SAML 支持 SSO(我们编写了自己的身份和服务提供程序)，并且我们使用我们的代码和第三方代码通过 LDAP 和 SSO 跨 Java 和其他应用程序共享凭证。好的一面是这都是基于标准的。阴暗的一面是标准是用英语交流的，而英语是有解释的。

我说这只是为了说它可以做到。我还使用简单的 Servlet 过滤器编写了临时的、在餐巾纸 SSO 实现的后面，包括同域和跨域(同域使用共享 cookie 很简单)。密码策略、密码恢复、保持 Activity 计时器、多窗口超时和 session 管理(这很重要)、角色、权限等。在那里，完成了。

此外，我不会提及 Spring 和 Spring Security，它们在 Spring 之上提供了所有这些。我没有使用过它(我不是 Spring 人)，但那些人确实知道他们在做什么，所以值得一看。