我目前正在研究在JBoss AS 7上运行的项目，该项目需要来自各种来源的身份验证。我试图了解组合提供身份验证的各种组件。
我对这一切如何融合有一些假设/猜测，但我需要确保我的理解是正确的。以下是我所理解的JBoss AS7的身份验证过程。
您有一个安全领域，用于定义用户的身份验证方式。然后，这个领域会暴露给您的应用程序，以保护其中的部分或全部内容。在AS7中，这是在＆lt; subsystem xmlns =“urn：jboss：domain：security：1.0”＆gt;中配置的。元件。
可以将领域配置为使用登录模块（例如数据库，LDAP，本地文件或其他内容）针对各种来源对用户进行身份验证。可以定义多个登录模块，您可以指定登录模块的某些组合必须“成功”才能进行身份验证。
实际的用户名和密码是通过web.xml文件（对于servlet）中定义的机制传递的，在＆lt; login-config＆gt;中定义。元件。
假设上述过程是正确的（可能不是）：
答案 0 :(得分：11)
JavaEE安全规范为容器实现者留下了很多空间，因此我将专注于JBoss实现来回答。
JBoss安全实施
JBoss依靠JAAS身份验证来实现JavaEE安全性。这样，它可以从稳定的API中获益，并且可以使用existing LoginModule implementations。登录模块用于验证主题，但也用于向Subject添加角色。 JAAS提供授权，权限检查机制，JBoss在内部使用它。
JAAS LoginModule不仅支持基于密码的身份验证，还支持基于令牌的身份验证。
基于令牌的身份验证
由于JAAS，可以在JBoss中完成的一个很好的例子是HTTP Negotiation support for Kerberos SPNEGO：由于Tomcat Authenticator和令牌验证使用了{JavaSE standard Kerberos LoginModule，因此实现了额外的auth-method SPNEGO ServletFilter 3}}
顺便说一句，LoginModule API不是必需的，它甚至可能对某些协议来说太复杂了。例如，支持OpenID with PicketLink的实现仅使用Servlet API。
第三方安全库
这些库通常为运行JavaEE或纯Java上下文的应用程序提供安全层，即使它没有从JavaEE规范中获益于身份验证或基于角色的授权。
Spring Security为应用程序开发人员提供了除JavaEE安全之外的其他抽象，以实现身份验证和授权，这主要得益于Web应用程序的{{1}}。可以使用大量选项来保护他的应用程序：可以混合多个选项，例如：JAAS用法，JavaEE容器安全性使用或Spring Security特定实现（OpenID和OAuth的情况）。不依赖于JavaEE，因此在JavaSE上运行时几乎可以在任何情况下使用它。大多数架构师选择在Spring Security上构建应用程序安全性，以便将来可以自由切换特定的实现。
Apache Shiro与Spring Security非常相似，但它更年轻，可能更容易设置。
Seam安全性不依赖于JavaEE安全性或JBoss，而只依赖于Servlet和JSF API。对于基于JSF / Seam的Web应用程序来说，这显然是最简单的选择。在幕后，它使用PicketLink实现。
作为结论，使用第三方库作为JavaEE安全性的补充或替代的问题取决于架构选择：应用程序复杂性，供应商独立性和可移植性，对错误修复或改进的实现的控制。在您的特定环境中，拥有多个身份验证源需要灵活的解决方案，如Spring Security，它支持authentication provider chaining（或Shiro）。