It sounds like you still need to flesh out your security model, but you will likely find you do not need something like OpenAM at all, and can just use container/framework provided security.
OpenAM has two separate stores, a User Store, where users and all the accompanying properties are stored and a Configuration Store, which holds the configuration. There is a database User Store, which is available in OpenAM however I have never tried it. The SO question you were pointing to was referring primarily to the config store, which while LDAP only, is embedded in OpenAM (so doesn't require direct management).
Personally I am a fan of Tomcat over Glassfish, as it is a fast and light Servlet container, without all the associated bloat which goes with a full J2EE container.
I have successfully build a custom user repository for OpenAm. Since this question have not been active for a while and because it would be too long to describe in details here how to do it, I will just give a few hints. If you need help on specifics, fell free to ask me.
Your basic entry point needs to extends com.sun.identity.idm.IdRepo.
You need to register your custom repository using ssoadm.jsp?cmd=add-sub-schema.
From this point, your repository type will be listed among the other types when you create a data store for a realm.
另外，如果我不提及 Spring 和 Spring Security，那就太失职了，它们在 Spring 之上提供了所有这些功能。我没有使用过它（我不是 Spring 的人），但那些人确实知道他们在做什么，所以值得一看。
Are you integrating existing applications, or do you just want to support your own applications?
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 is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server.
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.
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.
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.
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 can fix a lot of that, since you configure them all to use the same credential store.
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).
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
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.
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.
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
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.
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.
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.
Now, 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.
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).
But the devil is in the details. And, boy, are there devils.
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 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.
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.
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.
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.
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.
发布评论
评论（7）
请注意“
听起来您仍然需要充实您的安全模型，但您可能会发现您根本不需要像 OpenAM 这样的东西，而只需使用容器/框架提供的安全性。
Please note that "Is there a way to make OpenSSO/OpenAM talk to Database for its authentication and authorization?" is phrased wrong. The question details and answers only deal with the authorization aspect. OpenAM works great with a MySQL database of users and passwords (authentication), and can use it's hidden/embedded LDAP server for storing policies and other settings.
It sounds like you still need to flesh out your security model, but you will likely find you do not need something like OpenAM at all, and can just use container/framework provided security.
此列表可能提供一个很好的起点：
http://en.wikipedia.org/wiki/List_of_single_sign- on_implementations
与 JOSSO 和 Shibboleth 浮现在脑海中。
This list might provide a good starting point:
http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations
with JOSSO and Shibboleth springing to mind.
OpenAM 有两个独立的存储，一个是用户存储，其中存储用户和所有附带属性，另一个是配置存储，其中保存配置。 OpenAM 中有一个数据库用户存储，但我从未尝试过。您所指的 SO 问题主要指的是配置存储，虽然仅包含 LDAP，但它嵌入在 OpenAM 中（因此不需要直接管理）。
就我个人而言，我更喜欢 Tomcat，而不是 Glassfish，因为它是一个快速、轻量的 Servlet 容器，没有完整 J2EE 容器所带来的所有相关的膨胀。
OpenAM has two separate stores, a User Store, where users and all the accompanying properties are stored and a Configuration Store, which holds the configuration. There is a database User Store, which is available in OpenAM however I have never tried it. The SO question you were pointing to was referring primarily to the config store, which while LDAP only, is embedded in OpenAM (so doesn't require direct management).
Personally I am a fan of Tomcat over Glassfish, as it is a fast and light Servlet container, without all the associated bloat which goes with a full J2EE container.
您可以将 OpenAm 与 RDBM 结合使用。我在 OpenAm 中使用基于 JBDC 的用户存储
You can use OpenAm with RDBMs. I am using JBDC based user store in OpenAm
OpenAM 似乎能够插入您自己的身份验证模块。
据推测，您可以从 AMLoginModule 的扩展范围内进行数据库调用。
OpenAM seems to have the ability to plug in your own authentication module.
Presumably, you can make your DB calls from within your extentsion of the AMLoginModule.
我已成功为 OpenAm 构建自定义用户存储库。由于这个问题已经有一段时间没有活跃了，并且因为在这里详细描述如何做会太长，所以我只会给出一些提示。如果您需要具体帮助，请随时询问我。
从此时起，当您为领域创建数据存储时，您的存储库类型将列在其他类型中。
祝你好运 ！
I have successfully build a custom user repository for OpenAm. Since this question have not been active for a while and because it would be too long to describe in details here how to do it, I will just give a few hints. If you need help on specifics, fell free to ask me.
From this point, your repository type will be listed among the other types when you create a data store for a realm.
Good luck !
您正在集成现有应用程序，还是只想支持您自己的应用程序？
您是在寻找实际的 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 领域的细节在于它是容器的一个方面，而不是应用程序的一个方面。就像连接池是应用程序利用的容器资源一样。大多数人希望安全性成为他们的应用程序的一部分，他们觉得自己可以更好地控制它。
这一切都很好，直到您开始获得一堆不同的应用程序，并且每个应用程序的配置都不同，并且具有单独的用户列表和密码策略等。LDAP
可以解决很多问题，因为您将它们全部配置为使用相同的凭证存储。
Realm 满足了 Java EE 服务器上的这一需求。您的应用程序配置为使用容器提供的领域。如果您有多个应用程序和一个领域，那么它们都可以在该领域内共享凭据（无论领域类型如何）。
领域可以是任何东西：基于文件、基于数据库、LDAP 等。如果容器集群，领域也可以集群（这很方便）。
Java EE 安全性的阴暗面以及大多数应用程序避免使用它的原因是，由于 Realm 是容器的一部分，而不是应用程序的一部分，因此使用起来可能有点笨拙，并且可能无法提供您想要的功能。 但 Java EE 安全性的好处是，一旦您处于其保护之下
，您就可以轻松地在代码中充分利用凭证。一个人登录到该网站，该凭证可以在 Web 应用程序中使用，或者自动传播回 EJB 层（曾经是远程 EJB 层），并且该信息始终很方便。
您可以将 Web 应用程序指向某个领域、EJB、Web 服务。他们都利用相同的部分。
为了获得两全其美的效果，就是利用容器特定的机制来访问容器的安全性。这是 Java EE 安全性的另一个阴暗面。
领域之类的东西以及对容器安全性的直接访问不能跨容器移植。 GF 的做法与 Tomcat 的做法与 WebLogic 的做法不同。它们非常接近，但在细节上有所不同，因此您的代码无法无缝移植。
好的一面是对于内部应用程序来说，大多数人只是利用他们拥有的容器，对容器相关代码进行合理的抽象，然后就结束了，注意，是的，如果他们转移到不同的地方，他们将不得不移植它容器。但是，在实践中。就像数据库一样，一旦选择了容器平台，人们往往会紧紧依偎并坚持使用它。
最后，Servlet 3.0（在 GF3 和 Tomcat 7 中）标准化了更多的编程登录问题，使它们更易于跨容器移植，但基本概念是相同的。
现在，单点登录。
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 身份提供商等，但您的应用程序中仍然需要一个服务提供商）。
无论您选择什么协议，该过程基本上都是相同的（详细信息请参见 - 跨域登录 - 从一个域转移到另一个域时如何自动登录用户）。
但问题在于细节。还有，孩子，有魔鬼吗？
所有这些系统都很复杂。单点登录很复杂。例如，现在您已经有了单点登录，那么单点退出呢？单次超时怎么样？用户登录时凭证发生更改怎么办？您的 Web 服务的 STS（安全令牌服务）怎么样？ （STS 为 Web 服务提供了类似的委托身份验证机制。）
SAML 向您介绍了大量新词汇和大量配置。它不容易被接受，因为文档不是很好，并且很大程度上依赖于标准文档，这些标准文档涉及更高级别的通用事物，而不是专门针对您和您的应用程序。
如果您并不真正需要 SSO，那么您可能会对中央 LDAP 存储之类的东西感到满意，并从那里继续。
尽管如此，举个例子，我们的应用程序同时支持 DB 和 LDAP 后端。他们使用 Glassfish 和 Java EE 安全性。我们完全控制用户体验。我们还通过 SAML 支持 SSO（我们编写了自己的身份和服务提供商），并且我们使用我们的代码和第三方代码，通过 LDAP 和 SSO 跨 Java 和其他应用程序共享凭证。好的一面是这都是基于标准的。不利的一面是标准是用英语传达的，而英语是可以解释的。
我这么说只是为了说这是可以做到的。我还使用简单的 Servlet 过滤器编写了临时的餐巾纸背面 SSO 实现，包括相同域和跨域（相同域使用共享 cookie 很简单）。密码策略、密码恢复、保持活动计时器、多窗口超时和会话管理（这很麻烦）、角色、权限等等。去过那里，做过这些。
另外，如果我不提及 Spring 和 Spring Security，那就太失职了，它们在 Spring 之上提供了所有这些功能。我没有使用过它（我不是 Spring 的人），但那些人确实知道他们在做什么，所以值得一看。
Are you integrating existing applications, or do you just want to support your own applications?
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 is a common system used to manage a shared credential. Many systems allow you to point their authentication store to an existing LDAP server.
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.
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.
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.
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 can fix a lot of that, since you configure them all to use the same credential store.
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).
Realms can be anything: file based, db based, LDAP, etc. Realms also cluster if the container clusters (which can be handy).
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.
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.
You can point your web apps at a realm, you EJBs, your web services. They all leverage the same pieces.
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.
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.
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.
Now, 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.
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.
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 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.
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.
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.
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.
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.