OpenSSO/OpenAM替代品 [英] OpenSSO/OpenAM alternatives
问题描述
警告！我正在这里钓鱼，我甚至不确定我要问的问题是否完全有意义.请您对我的回答好！:)
Warning! I'm on a bit of a fishing trip here, and I'm not even sure if the questions that I'm asking entirely make sense. Please be kind with your responses! :)
我最近接手了一个当前基于Java + Linux + Tomcat + MySQL的项目.现在，该系统基本上只是一个网站，在后台有一些cron作业来移动一些数据，等等.在与产品经理一起开发优先的待办事项列表时，很明显，他想做什么需要开始开发面向服务的体系结构(SOA<-流行语警告！)，最后我将混合使用Web服务器和应用程序服务器.注意:我强烈考虑迁移到Glassfish v3.
I recently took over a project that is currently based on a Java + Linux + Tomcat + MySQL. Right now, the system is basically just a website with a few cron jobs in the back-ground to move some data around, etc. In working with the product manager to develop a prioritized backlog, it’s clear from what he wants to do that I need to start developing a service-oriented architecture (SOA <-- buzz word warning!), and I will end up with a blend of web servers and application servers. Note: I’m strongly considering moving to Glassfish v3.
当前，身份验证和授权是用Java代码处理的，用户信息存储在MySQL数据库中.在最低限度上，在我看来，我将需要将其拆分为单独的身份验证服务(否则，最终将在各处放置一堆重复的代码来处理用户身份验证和授权).
Currently, authentication and authorizations are handled in Java code with user information being stored in the MySQL database. At the bare minimum, it seems to me that I will need to split this out into a separate authentication service (otherwise, will end up with a bunch of duplicate code all over the place to handle user authentication and authorizations).
我一直在研究单点登录(SSO) type 解决方案，并进行了一些研究.据我所知，OpenSSO已被Oracle正式放弃，但被ForgeRock收购，现在被称为OpenAM.这似乎与我想要的非常接近，但是由于我已经有一个基于MySQL的系统，所以我希望有一些支持它的东西(或其他某种RDBMS).我在Stack Overflow上找到了它，似乎表明它基本上是LDAP或什么也没有.
I’ve been looking into single sign-on (SSO) type solutions and doing some research. From what I can gather, OpenSSO has been officially dropped by Oracle, but picked up by ForgeRock and now is called OpenAM. This appears to be very close to what I want, but since I already have a MySQL-based system, I would prefer to have something that supports it (or some other kind of RDBMS). I found this on Stack Overflow and it seems to indicate that it’s basically LDAP or nothing.
是否有办法使OpenSSO/OpenAM与数据库对话以进行身份验证和授权?
我的问题是:
OpenSSO/OpenAM还有哪些其他选择?LDAP是要走的路吗?注意:进行"OpenAM vs" Google搜索不会产生太大的效果.人们会倾向于自己滚"吗?
What other options are out there to OpenSSO/OpenAM? Is LDAP the way to go? Note: doing a "OpenAM vs" google search doesn’t yield much. Do people tend to just "roll their own"?
对此主题的任何想法/建议/链接都将有助于教育我.预先感谢您的耐心配合和帮助.
Any thoughts/suggestions/links on this topic that will help educate me will be greatly appreciated. Thanks in advance for your patience and help.
推荐答案
您是要集成现有应用程序，还是只想支持自己的应用程序?
Are you integrating existing applications, or do you just want to support your own applications?
您要查找实际的SSO还是只是共享凭据?SSO正在登录到单个应用程序，并将该凭据传播到另一个应用程序(例如，登录Gmail并自动登录到Blogger).共享证书是您可以在应用程序之间使用相同的登录名和密码，但是证书本身不会自动传播.
Are you looking for actual SSO or simply shared credentials? SSO is logging in to a single application, and having that credential propagate to another application (such as logging in to Gmail and being automatically logged in to Blogger). Shared credential is you can use the same login name and password across applications, but the credential itself is not automatically propagated.
LDAP是用于管理共享证书的通用系统.许多系统允许您将其身份验证存储区指向现有的LDAP服务器.
LDAP is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server.
例如，如果您在Java EE容器中部署了多个应用程序，并且还有一个电子邮件服务器和基于Web的电子邮件客户端，那么所有这些不同的应用程序都可以指向同一LDAP服务器，并且您的用户将拥有所有不同系统的单一登录名和密码，都用不同的语言编写，并且都部署在不同的计算机上.这是LDAP的一个用例，几乎每个系统都可以立即使用.Glassfish和Tomcat都可以轻松地针对LDAP服务器进行验证.Apache(Web服务器)，Postgres(数据库)，Postfix(电子邮件)等也可以.
For example, if you had several apps deployed in a Java EE container, and also, say, an email server and web based email client, all of these diverse applications could be pointed to the same LDAP server and your users would have a single login and password for all of the different systems, all written in different languages, all deployed on different machines. This is a bread and butter use case of LDAP, and pretty much every system can handle this out of the box. Glassfish and Tomcat can both readily validate against an LDAP server. So can Apache (Web server), Postgres (Database), Postfix (email), etc. etc.
因此，如果您仅需要共享证书，则可以通过安装LDAP服务器来免费"获得该证书.LDAP与DBMS有点不同，但是一旦您对其进行了一点研究并了解"，它的确非常不错.OpenLDAP是一种流行的LDAP服务器，但是我偏爱ApacheDS.
So if you want simply a shared credential, you get that "for free", right now, by installing an LDAP server. LDAP is a bit of a different beast than something like a DBMS, but once you study it a little and "get it", it's really quite nice. OpenLDAP is a popular LDAP server, but I'm partial to ApacheDS.
在Java EE容器中进行设置的方法是设置领域".GF和Tomcat都有LDAP领域，我想其余的都可以.但是要点在于，您需要使用Java EE安全性来利用Realm.
The way to set that up in a Java EE container is to set up a "Realm". GF and Tomcat both have LDAP realms out of the box, I imagine the rest do to. But the nut there is that you need to use Java EE security to leverage the Realm.
看，Java EE领域的细节在于它是容器的一个方面，而不是应用程序.就像连接池是您的应用程序利用的容器资源一样.大多数人希望安全性成为其应用程序的一部分，他们觉得可以对其进行更多控制.
See, the detail with a Java EE Realm is that it's an aspect of the CONTAINER, not the application. Just like a connection pool is a container resource that your application leverages. Most people want security to be a part of their application, where they feel they have more control over it.
这一切都很好，直到您开始获得一堆不同的应用程序，并且每个人的配置都不同并且具有单独的用户列表和密码策略等为止.
That's all well and good until you start getting a bunch of different applications and everyone is configured differently and has separate user lists, and password policies, etc. etc.
LDAP可以解决很多问题，因为您将它们都配置为使用相同的凭据存储.
LDAP can fix a lot of that, since you configure them all to use the same credential store.
领域满足了Java EE服务器上的需求.您的应用程序被配置为使用容器提供的领域.如果您有多个应用程序和一个Realm，则它们都将在该Realm中共享凭据(无论Realm类型如何).
The Realm fills that need on a Java EE server. Your application is configured to use a Realm provided by the container. If you have several applications, and a single Realm, then they all get to share the credentials within that Realm (regardless of the Realm type).
领域可以是任何东西:基于文件，基于数据库，LDAP等.如果容器群集(可以方便使用)，则领域也会群集.
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
Java EE安全性的阴暗面，以及为什么大多数应用程序避免这样做的原因是，因为Realm再次是容器的一部分，而不是应用程序的一部分，所以使用起来可能有点笨拙，也许无法提供在用户管理，密码策略等方面喜欢的功能.
The dark side of Java EE security, and why most apps avoid it is that, since, again, the Realm is part of the container, and not the application, it can be a little ungainly to use, and perhaps not offer the features you like in terms of user management, password policies, etc.
但是Java EE安全性的亮面是，一旦掌握了它，您就可以轻松地在代码中充分利用整个凭据.一个人登录到该网站，该凭据可以在该Web应用程序中使用，也可以自动传播回EJB层(无论是远程EJB层)，并且该信息始终很方便.
But the bright side of Java EE security is that once you're under its umbrella, you can leverage the credential all over in your code easily. A person logs in to the web site, and that credential can be used there in the web app, or automatically propagated back to the EJB tier (ever a remote EJB tier), and the information is always handy.
您可以将Web应用程序指向某个领域，EJB，Web服务.它们都利用相同的碎片.
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
为了获得两全其美的好处，就是要利用特定于容器的机制来访问容器的安全性.这是Java EE安全性的另一面.
In order to get kind of the best of both worlds is to leverage container specific mechanisms to access the containers security. This is the other dark side of Java EE security.
诸如领域之类的东西以及对容器安全性的直接访问不能跨容器移植.GF与Tomcat的不同之处在于它与WebLogic的不同之处.一切都非常接近，但是细节有所不同，因此您的代码将无法无缝移植.
Things like Realms, and direct access to container security are not portable across containers. GF does it different than Tomcat does it different from WebLogic. It's all really close, but differs in details so your code won't port seamlessly.
对于内部应用程序来说，好的一面是内部应用程序，大多数人只是简单地利用他们拥有的容器，对依赖于容器的代码进行合理的抽象，并称其为白天"，请注意，如果移动它们，则必须移植此代码.到另一个容器.但是，在实践中.就像数据库一样，一旦选择了容器平台，人们往往会紧紧抓住并坚持使用它.
The bright side is for in house apps, most folks simply leverage the container they have, put a reasonable abstraction around the container dependent code, and call it day noting that yes, they will have to port this if and when they move to a different container. But, in practice. much like a database, once a container platform is chosen, folks tend to snuggle in tight and stick with it.
最后，Servlet 3.0(在GF3和Tomcat 7中)对更多的编程式登录问题进行了标准化，以使其在容器之间的可移植性更高，但是基本概念相同.
Finally, Servlet 3.0 (In GF3 and Tomcat 7) standardizes more of the programmatic login issues to make them more portable across containers, but the underlying concepts are the same.
现在，SSO.
SSO是另一种野兽.但是，GF和Tomcat都支持Web应用程序的SSO.这使您可以登录到一个Web应用程序，并且无需登录即可轻松访问其他Web应用程序.但是SSO有点受限制，因为它在很大程度上依赖于容器安全性及其生命周期，而不是在应用程序的控制下更加灵活.注意，不仅要在Realms(这是给定的)上，还要在实际的基于容器的FORM登录名上，而不是在自定义程序化登录名上.FORM登录并不引人注目，但它可以正常工作.实施一个Realm，将您的应用程序部署到Tomcat或GF(或GF 3.1中的集群)的单个实例上，您就可以免费获得SSO，因此，如果重要的话，这真的很不错.对于后台应用程序，它的可用性很好，但对于公共互联网可能不是.
SSO is a different beast. But, out the gate, both GF and Tomcat support SSO for web apps. This lets you log in to one web app and have be able to easily access others without having to log in to them. But the SSO is a little bit limited since it relies more heavily on the container security and its lifecycle, rather than a more flexible one under the control of the application. Mind, not just on Realms (that's a given), but on the actual container based FORM login, rather than a custom programmatic login. FORM login is not spectacular, but it's functional and it works. Implement a Realm, deploy your apps to a single instance of Tomcat or GF (or a cluster in GF 3.1), and you get SSO for free, so if that's important, it's kind of nice really. It's usability is fine for back office apps, but not perhaps the public internet.
如果您需要更复杂的SSO解决方案，则需要查看自定义实现.OpenSSO就是其中之一，它依赖于SAML和SAML Web配置文件.但是，还有其他.还有CAS，Atlassian Cloud，Kerberos和OAuth.这些协议都使用与SAML不同的协议.如果您想坚持使用SAML，还可以查看Shibboleth，甚至是SimpleSAML(SimpleSAML是充当SAML身份提供程序的PHP服务器，但在应用程序中仍然需要服务提供程序).
If you want a more sophisticated SSO solution, then you need look at custom implementations. OpenSSO is one of those, and it relies on SAML and the SAML web profile. However, there are others. There's CAS, Atlassian Cloud, Kerberos, and OAuth as well. Those are all using different protocols than SAML. If you want to stick with SAML you can also look at Shibboleth, or even SimpleSAML (SimpleSAML is a PHP server that acts as a SAML Identity Provider, among other things, but you still need a Service Provider within your applications).
Whatever protocol you choose, the process is basically the same (detailed here -- Cross Domain Login - How to login a user automatically when transferred from one domain to another).
但是细节决定成败.而且，男孩，那里有魔鬼.
But the devil is in the details. And, boy, are there devils.
所有这些系统都很复杂.SSO很复杂.例如，既然您具有单一登录"功能，那么单一登录"功能又如何呢?单次超时怎么办?用户登录后的凭据更改如何处理?您的Web服务的STS(安全令牌服务)呢?(STS为Web服务提供了类似的委托身份验证机制.)
All of these systems are complicated. SSO is complicated. For example, now that you have Single Sign On, what about Single Sign Out? What about Single Time Out? What about credential changes while users are logged in? What about an STS (Secure Token Service) for your Web Services? (STS offers a similar delegated authentication mechanism for web services.)
SAML向您介绍了很多新词汇和很多配置.由于文档不是很出色，并且很大程度上依赖于标准文档，而这些文档与更高层次的通用事物有关，而不是专门针对您和您的应用程序，因此它不容易被采用.
SAML introduces you to a whole lot of new vocabulary, and a lot of configuration. It's not readily picked up since the documentation isn't stellar and relies a lot on standards documents which talk to a higher level of generic things, and not to you and your application specifically.
如果您真的不需要SSO，那么您可能会满意中央LDAP存储之类的东西，然后从那里开始.
If you don't need really need SSO, then you'll likely be content with something like a central LDAP store and going on from there.
举例说明，我们的应用程序同时支持数据库和LDAP后端.他们使用Glassfish和Java EE安全性.我们完全控制用户体验.我们还通过SAML(我们编写了自己的身份和服务提供商)支持SSO，并且使用我们的代码和第三方代码在Java和其他应用程序中通过LDAP和SSO共享了凭据.好的方面是这是所有基于标准的.阴暗的一面是，标准以英语进行交流，而英语则受到解释.
All that said, as an example, our applications support both a DB and LDAP backend. They use Glassfish, and Java EE security. We completely control the user experience. We also support SSO via SAML (we wrote our own Identity and Service Providers), and we have both shared credentials via LDAP and SSO across Java and other applications, using our code and third party code. The bright side is this is all standards based. The dark side is that standards are communicated in english, and english is subject to interpretation.
我说这只是说可以做到.我还使用简单的Servlet过滤器在餐巾纸SSO实现的后面专门编写了相同的域和跨域(相同的域对于共享cookie来说很简单).密码策略，密码恢复，活动计时器，多个窗口超时和会话管理(这是很麻烦的)，角色，特权等.在此完成.
I say this simply to say it can be done. I have also written ad hoc, back of the napkin SSO implementations, both same domain and cross domain (same domain is simple with a shared cookie) using simple Servlet Filters. Password policies, password recovery, keep alive timers, multiple window timeout and session management (that's a hoot), roles, privileges, etc. etc. Been there, done that.
此外，我不会忘记不提及Spring和Spring Security，它在Spring之上提供了所有这些功能.我没有使用过它(我不是Spring的人)，但是那些人确实知道他们在做什么，所以值得一看.
Also, I would be remiss to not mention Spring and Spring Security which offers all of this on top of Spring. I have not used it (I'm not a Spring person), but those folks do know what they are doing so it's worth looking at.
这篇关于OpenSSO/OpenAM替代品的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
