java - 钩住容器要求LDAP用户角色的过程

Question

在我的应用程序中，我将基于表单的身份验证与LDAP-Realm结合使用。对于授权，我使用数据库。据我了解，这如下

App  --> (user, pass) --> LDAP 
     <--    OK, user exists --

     --> ask for security roles for 'user' --> JACC / Database
     <--              Administrator         --

我可以进入我的应用程序调用 ask for security roles for 'user'的过程吗？

背景：

LDAP说： Okay, 'user' is authentified

数据库： give me all roles where username = user

现在，我想自定义数据库查询： give me all roles where username = 'user' AND some more attributes

这可能吗？

Answer 1

TL; DR：查看示例解决方案的this和that。



您所要求的取决于您所使用的特定于供应商的功能所提供的灵活性。您的产品可能会或可能不会允许您扩展/ cc这些LoginModule / Realm / IdentityStore /的行为，无论它是什么/被称为专有类，甚至可能只是键入一个SQL查询到某些管理UI的输入字段。最重要的是，它是非标准功能。

在标准Java EE方面，有JASPIC（用户/消息身份验证）和JACC（授权）SPI。两者都可用于从某些外部存储中检索与您的用户有关的安全性相关信息。 JASPIC不能做的是在验证后更改用户的角色；也就是说，在经过身份验证的请求1期间，用户角色是固定的。 JASPIC也不能赋予这些角色以含义；为此，它们只是AS会以某种专有方式派生组String的普通Principal。另一方面，JACC可以做这些事情，因为它建立了一个“规则库”（认为是Policy），该规则库将角色，主体和Permissions精确地关联起来，并且可以在每个用户系统的每次交互中进行查询。 JACC还可以覆盖或更改对通过部署描述符和注释表示的Java EE安全约束的解释。

我将在本文中包括一个基于JASPIC的解决方案，而在大多数情况下将忽略JACC，因为：


您可能不需要JACC提供的其他灵活性。
使用自定义JACC提供程序解决方案需要quite a bit of work，但由于特定于AS的组到角色映射，因此仍不是100％标准的。
我没有意识到使用定制的JACC提供程序来完成有意义的事情的开源项目。唯一的例外是Java EE完整概要文件实现AS，因为它们被要求实施规范，有时甚至在内部使用其JACC提供程序（例如，对于GlassFish）。
围绕JASPIC仍然有很多困惑（许多开发人员都不知道它甚至存在），这是两个规范中最简单的一种。在继续讨论JACC之前，首先让JASPIC广为人知并“吸引”更多人是不合理的。
尽管现在在线JASPIC上不仅有很多很棒的例子，还有一些通过JASPIC提供程序实现实际身份验证的项目，但是-如果我弄错了，请更正我-在这里还没有找到完整的JASPIC示例。


关于以下内容的一些评论：


如果您的应用程序/ AS /系统爆炸或被外星人/等入侵，则不提供任何担保/使用风险自负/不起诉我。
请，请忽略那些您认为必须进行优化，更好的设计或其他改进的地方。是的，您可以承认可以重复使用DB / LDAP连接；验证插入LDAP搜索过滤器中的用户名；更关心线程安全；使用TLS;返回400以表示格式不正确的XML有效负载...。解决这些问题不在提供的解决方案的范围内。劳驾？？您想知道单元测试在哪里吗？对不起，没听说过这个词！ :)
提供了两个具体执行身份验证和组（角色）检索的SAM：一个“独立”功能，它自己完成两个任务；一个“委派”功能，其名称表明，它演示了SAM如何委派实际的身份验证。通过使用JASPIC LoginModule桥配置文件，可以工作到JAAS LoginModule（LM）。后者SAM需要在AS和本身在源级别进行进一步的配置/调整，除非您使用的是GlassFish。提供了随附的示例JAAS login.conf条目。
提供程序类已针对GlassFish 4.1进行了测试。他们努力保持符合规范，因此，如果您的产品实现了Full Java EE（6，最好是7）概要文件，那么它们也应该在您的AS上也确实可以工作（显然，第二个SAM除外）。如果没有，我很抱歉；不，我不会在您的AS上进行测试。
您可以避免研究/使用AuthConfigProvider和ServerAuthConfig实现，但随后必须以专有方式（通过特定于供应商的AuthConfigFactory和/或进一步使用）向产品的foo-web.xml注册实际的SAM。部署/管理工具）。此外，您将没有SAM实现ServerAuthContext接口，并且必须从SAM中加载随附的Properties。然后，您的AS将为您实例化缺少的类，可能会重用针对所有应用程序和消息层预先配置的“全局” AuthConfigProvider和/或ServerAuthConfig。请注意，取决于它是否在请求之间重用实例化的ServerAuthConfig和ServerAuthContext（几乎没有这种情况，尤其是后者），SAM的生命周期可能会受到影响。
由于特定于容器，因此未涵盖组到角色的映射。
我想在任何地方添加评论。并非全部（完全）无用。在规范的帮助下，代码应该易于理解-但请随时询问是否有问题困扰您。对于超长帖子表示歉意。
从标准Maven项目的根开始，路径是绝对的。适应SAM中的属性和/或身份验证/组检索方法后，您可以将所有文件构建为WAR，然后将其按原样部署在AS上进行测试。唯一的依赖关系是（provided）javaee-api 7.0（加上JDBC驱动程序，除非AS类路径上已经存在）。
由于SO的帖子长度限制，我不得不将代码移至Gist。





ServletContextListener注册AuthConfigProvider。另存为/<project>/src/main/java/org/my/foosoft/authn/BigJaspicFactoryRegistrar.java。
AuthConfigProvider。另存为/<project>/src/main/java/org/my/foosoft/authn/BigJaspicFactory.java。
ServerAuthConfig。另存为/<project>/src/main/java/org/my/foosoft/authn/LittleJaspicServerFactory.java。
基本双重ServerAuthContext - ServerAuthModule实现帮助程序类。这是实际答案的1/3。另存为/<project>/src/main/java/org/my/foosoft/authn/HttpServletSam.java。
standalone SAM实现。实际答案，第2/3部分。另存为/<project>/src/main/java/org/my/foosoft/authn/StandaloneLdapSam.java。
JAAS LM-delegating SAM。实际答案，第3/3部分。另存为/<project>/src/main/java/org/my/foosoft/authn/JaasDelegatingLdapSam.java。
便利exception type。另存为/<project>/src/main/java/org/my/foosoft/authn/JaspicMischief.java。
随附的Properties。如果您想逐字测试实际的身份验证代码，请使其适应您的需求。另存为/<project>/src/main/resources/org/my/foosoft/authn/jaspic-provider.properties。
伴随（aa）的代码片段（6）；有关实际文件系统位置，请参阅供应商的文档。
login.conf（可选-用于演示：sample /<project>/src/main/java/org/my/foosoft/presentation/UserUtils.java）
/<project>/src/main/webapp/index.xhtml（可选-用于演示：JSF backing bean）
/<project>/src/main/webapp/login.xhtml（可选-用于演示：unprotected index page）
/<project>/src/main/webapp/restricted/info.xhtml（可选-出于演示目的：login page用于角色access_restricted_pages的用户）
/<project>/src/main/webapp/WEB-INF/web.xml（可选-出于演示目的和出于完整性考虑：protected index page）




进一步阅读：


web module DD
JSR-196 (JASPIC) Specification Arjan Tijms's
JASPIC ZEEF page




1 JASPIC是非常通用的SPI，从理论上讲，当插入有能力的消息处理运行时时，它就可以对JMS，SAML-over-SOAP和任何其他类型的消息进行身份验证。即使它主要用于Servlet容器配置文件，也不会过度限制它。

JASPIC的低级，灵活的性质导致对协议特定功能（例如HTTP会话）的不了解。因此，运行时会触发ServerAuthContext / SAM，以对每个请求执行身份验证。

但是，该规范通过允许SAM通过MessageInfo回调属性在运行时请求容器身份验证会话的初始化来对此潜在的缺陷作了规定。当要求对同一客户端的后续请求进行身份验证时，SAM可以通过要求运行时重新使用先前建立的AS身份验证会话，从而避免用户身份（调用方和/或组Principal）来重复整个过程。这是通过执行示例代码HttpServletSam中所示的“不做/离开身份验证状态为协议”来完成的。

最后应该指出，JASPIC和Servlet规范都没有明确定义什么是容器认证会话。对于SAM身份验证的用户，出于所有实际目的，我将认为AS身份验证会话与HTTP会话等效，只要a）身份验证涉及单个应用程序上下文，b）SAM，如上所述，表示在每个请求上重复使用AS身份验证会话。