OpenSSO/OpenAM替代方案

Question

警告!我在这里有点钓鱼之旅,我甚至不确定我问的问题是否完全有意义.请善意回复你!:)

我最近接手了一个目前基于Java + Linux + Tomcat + MySQL的项目.现在,该系统基本上只是一个在后台有一些cron工作的网站,可以移动一些数据等等.在与产品经理合作开发优先顺序时,很清楚他想做什么我需要开始开发面向服务的体系结构(SOA < - buzz word warning!),最终我将结合使用Web服务器和应用程序服务器.注意:我正在考虑转向Glassfish v3.

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

我一直在研究单点登录(SSO)类型解决方案并进行一些研究.从我可以收集的信息来看,OpenSSO已被Oracle正式删除,但被ForgeRock收录,现在被称为OpenAM.这似乎非常接近我想要的,但由于我已经有一个基于MySQL的系统,我宁愿有一些东西支持它(或其他一些RDBMS).我在Stack Overflow上找到了它,它似乎表明它基本上是LDAP或什么也没有.

有没有办法让OpenSSO/OpenAM与数据库通信以进行身份​​验证和授权？

我的问题是:

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容器中设置它的方法是设置"Realm".GF和Tomcat都有开放式的LDAP领域,我想其余的都是这样做的.但是,你需要使用Java EE安全性来利用Realm.

请参阅Java EE Realm的详细信息,它是CONTAINER的一个方面,而不是应用程序.就像连接池是应用程序利用的容器资源一样.大多数人都希望安全性成为他们应用程序的一部分,他们认为安全性可以更好地控制它.

这一切都很好,直到你开始获得一堆不同的应用程序,每个人都配置不同,并有单独的用户列表和密码策略等.

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.

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

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

无论您选择哪种协议,流程基本相同(详细说明 - 跨域登录 - 如何在从一个域转移到另一个域时自动登录用户).

但魔鬼在于细节.而且,男孩,有魔鬼吗？

所有这些系统都很复杂.SSO很复杂.例如,既然您已经单点登录,那么单点登录呢？单次超时怎么样？用户登录时凭据更改怎么办？您的Web服务的STS(安全令牌服务)怎么样？(STS为Web服务提供了类似的委托身份验证机制.)

SAML向您介绍了大量新词汇和大量配置.由于文档不是很出色,并且很依赖标准文档,而这些标准文档与更高级别的通用事物相关,而不是特别针对您和您的应用程序,所以它不容易被提取.

如果您不需要真正需要SSO,那么您可能会满足于像中央LDAP存储这样的东西.

总而言之,我们的应用程序支持DB和LDAP后端.他们使用Glassfish和Java EE安全性.我们完全控制用户体验.我们还通过SAML支持SSO(我们编写了自己的身份和服务提供商),并且我们使用我们的代码和第三方代码通过Java和其他应用程序的LDAP和SSO共享凭据.光明的一面是这是所有标准的基础.黑暗的一面是标准用英语传达,英语需要解释.

我这样说只是为了说它可以做到.我还使用简单的Servlet过滤器编写了ad hoc,背面的SSO实现,相同的域和跨域(相同的域很简单,使用共享cookie).密码策略,密码恢复,保持活动计时器,多窗口超时和会话管理(这是一个hoot),角色,特权等等.去过那里,做到了.

另外,我不想提及Spring和Spring Security,它提供了Spring之上的所有功能.我没有用它(我不是春天的人),但那些人确实知道他们在做什么,所以值得一看.