挂起容器请求LDAP用户角色的进程 [英] Hook on process where container asks for roles of LDAP user

问题描述

在我的应用程序中，我使用LDAP-Realm进行基于表单的身份验证。对于授权，我使用数据库。据我所知，其工作原理如下：

In my application I use form-based authentication with a LDAP-Realm. For Authorization I use a database. As I understand this works as follows

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

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

我可以挂钩进程我的应用程序调用询问'user'的安全角色？

Can I hook into the process where my application calls ask for security roles for 'user'?

背景：

LDAP说：好的，'用户'已经过身份验证

数据库：给我所有的角色，其中username = user

和现在我想自定义数据库查询： 给我所有的角色，其中username ='user'和更多属性

And now I want to customize the Database query: give me all roles where username = 'user' AND some more attributes

这有可能吗？

推荐答案

TL; DR：看看这个和那个样本解决方案。

TL;DR: Have a look at this and that for a sample solution.

您要求的内容取决于您使用的供应商特定功能提供的灵活程度;您的产品可能会或可能不会允许您扩展/这些 LoginModule / Realm / <$ c $的行为c> IdentityStore / what-it's /他们称为专有类，或者甚至只是在一些管理UI的输入字段中键入SQL查询。底线是它的非标准功能。

What you ask for depends on the degree of flexibility offered by the vendor-specific feature you use; your product may or may not allow you to extend the behaviour of that/these LoginModule / Realm / IdentityStore / whatever-it's/they're-called proprietary class(es), or maybe even to just type an SQL query into some administrative UI's input field. The bottom line is that it's non-standard functionality.

在频谱的标准Java EE方面，有 JASPIC （用户/消息）身份验证）和 JACC （授权）SPI。两者都可用于从某些外部存储中检索与用户相关的安全相关信息。 JASPIC无法做的是在身份验证后更改用户的角色;也就是说，在经过身份验证的请求 ¹ 的持续时间内，用户的角色是已修复。 JASPIC也不能将含义附加到这些角色;对于它来说，它们只是简单的字符串 s，AS将以某种专有方式从中派生出组 Principal 。另一方面，JACC可以做这些事情，因为它建立了一个规则库（想想 政策 ）精确关联角色，主体和 权限 s 并且可以在每个用户上查询 - 系统互动。 JACC还可以覆盖或更改通过部署描述符和注释表达的Java EE安全约束的解释。

On the standard Java EE side of the spectrum there are the JASPIC (user / message authentication) and JACC (authorization) SPIs. Both can be used to retrieve security-related information pertaining to your users from some external store. What JASPIC cannot do is change a user's roles after authentication; that is, for the duration of an authenticated request ¹ the user's roles are fixed. JASPIC can also not attach meaning to those roles; for it they're just plain Strings that the AS will in some proprietary manner derive group Principals from. JACC, on the other hand can do those things, as it establishes a "rulebase" (think Policy) which precisely associates roles, principals and Permissions and can be queried on each and every user-system interaction. JACC can also override or alter the interpretation of the Java EE security constraints expressed via deployment descriptors and annotations.

我将在此帖中包含基于JASPIC的解决方案并忽略JACC在大多数情况下，因为：

I will include a JASPIC-based solution in this post and disregard JACC for the most part, because:

• 您可能不需要JACC提供的额外灵活性。


• 使用自定义JACC提供商解决方案需要相当 有点 < a href =http://arjan-tijms.omnifaces.org/2015/03/java-ee-authorization-jacc-revisited.html =nofollow noreferrer>工作并且仍然不是100由于AS特定的组到角色映射而导致的标准百分比。


• 我不知道使用自定义JACC提供程序来完成有意义的事情的开源项目; Java EE Full Profile-实现AS是唯一的例外，因为他们被要求实施规范，有时也在内部使用他们的JACC提供者（例如在GlassFish的情况下）。


• 这是围绕JASPIC仍然存在很多困惑（很多开发人员都不知道它甚至存在），这是两个规范中最简单的一个。在继续报道JACC之前，首先让JASPIC为更多人所知并且平易近人是不合理的。


• 虽然现在JASPIC上有很多很好的例子，但是通过JASPIC提供商实现实际身份验证的项目，如果我错了，请更正我 - 我还没有在SO上找到完整的JASPIC示例。

• You may not need the additional flexibility that JACC offers.
• Employing a custom JACC provider solution requires quite a bit of work and is still not 100% standard due to AS-specific group-to-role-mapping.
• I'm unaware of an open-source project using a custom JACC provider for accomplishing something meaningful; Java EE Full Profile-implementing AS's being the sole exception, as they are mandated to implement the spec and sometimes use their JACC providers internally too (as e.g. in the case of GlassFish).
• There's still a lot of confusion surrounding JASPIC (many developers are unaware it even exists) which is the simplest one of the two specs. It's imho reasonable to first make JASPIC known and "approachable" to more people before moving on to covering JACC.
• While there are now more than a mere few great examples on JASPIC online, as are projects implementing actual authentication via JASPIC providers, -correct me if I'm mistaken- I haven't yet found a complete JASPIC example here on SO.

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

Some remarks on what follows:

• 如果您的app / AS不承担任何保修/使用风险/不起诉我/系统爆炸或被外星人/等人攻击。


• 请尽量忽视那些优化，更好的设计或其他改进在您认为必不可少的地方。是的，你可以承认重用DB / LDAP连接;验证插入LDAP搜索过滤器的用户名;更关心线程安全;使用TLS;为非格式良好的XML有效负载返回400 ...解决这些问题超出了所提供解决方案的范围。劳驾？？你想知道单元测试在哪里???对不起，从来没有听说过这个词！ ：）


• 提供了两个具体执行组（角色）身份验证和检索的SAM：独立，它自己完成两个任务，以及委托任务，其中，顾名思义，演示SAM如何将实际身份验证工作委托给JAAS LoginModule （LM），使用JASPIC LoginModule Bridge Profile 。后者SAM需要在AS和源级本身进行进一步的配置/调整，除非您使用的是GlassFish。提供了一个附带的示例JAAS login.conf 条目。


• 提供程序类是针对GlassFish 4.1进行测试的。他们努力保持规范兼容，因此，如果您的产品实现了完整的Java EE（6，最好是7）配置文件，那么它应该真正适用于您的AS（显然除了第二个SAM）。如果没有，我很抱歉;不，我不会测试你的AS。


• 你可以避免学习/使用 AuthConfigProvider 和 ServerAuthConfig 实现，但必须在产品的 AuthConfigFactory 以专有方式（通过供应商特定的 foo-web.xml 和/或进一步使用部署/管理工具）。另外你没有SAM实现 ServerAuthContext 界面，必须从SAM中加载随附的属性。然后，您的AS将为您实例化缺少的类，可能重用全局 AuthConfigProvider 和/或 ServerAuthConfig 它具有为所有应用程序和消息层预先配置。请注意，取决于它是否在请求之间重用其实例化的 ServerAuthConfig 和 ServerAuthContext （几乎没有特别是后者），您的SAM的生命周期可能会受到影响。


• 不包括组到角色映射，因为它是特定于容器的。


• 我包括评论无论我在哪里这样做。并非所有（完全）都无用。在规范的帮助下，代码应该是可理解的 - 但是可以随意询问是否有什么问题困扰着你。为超长帖子道歉。


• 路径绝对来自标准Maven项目的根。一旦在SAM中调整了属性和/或身份验证/组检索方法，就可以将所有文件构建为WAR，并在AS上按原样部署后者进行测试。唯一的依赖是（提供） javaee-api 7.0（加上你的JDBC驱动程序，除非已存在于AS类路径）。


• 我不得不将代码移到要点由于SO的帖子长度限制。

• No warranty / use at own risk / don't sue me if your app / AS / system explodes or gets hacked by alien / etc.
• Please, try to disregard those spots where optimization, better design or other improvements would in your opinion have been essential. Yes you could admittedly reuse DB / LDAP connections; validate usernames inserted into LDAP search filters; care more about thread safety; use TLS; return a 400 for non-well-formed XML payloads... . Addressing those concerns is outside the scope of the provided solution. Excuse me?? You wonder where the unit tests are???! Sorry, never heard of the term! :)
• Two SAMs concretely performing authentication and retrieval of groups (roles) are provided: a "standalone", which accomplishes both tasks on its own, and a "delegating" one, which, as its name suggests, demonstrates how a SAM can delegate actual authentication work to a JAAS LoginModule (LM), by employing the JASPIC LoginModule Bridge Profile. The latter SAM requires further configuration / adaptation, both at the AS and at the source level per se, except if you are using GlassFish. An accompanying example JAAS login.conf entry is provided.
• The provider classes were tested against GlassFish 4.1. They strive to remain spec-compliant and should therefore really work on your AS too (except for the second SAM, obviously), provided that your product implements the Full Java EE (6, preferably 7) Profile. I'm sorry if it doesn't; and no, I won't test on your AS.
• You can avoid studying / using the AuthConfigProvider and ServerAuthConfig implementations, but will then have to register the actual SAM with your product's AuthConfigFactory in a proprietary way (via a vendor-specific foo-web.xml and/or further use of deployment / administrative tools). You will additionally not have the SAM implementing the ServerAuthContext interface and will have to load the accompanying Properties from within the SAM. Your AS will then instantiate the missing classes for you, possibly reusing a "global" AuthConfigProvider and/or ServerAuthConfig it has pre-configured for all applications and message layers. Note that, depending on whether it reuses its instantiated ServerAuthConfig and ServerAuthContext across requests (hardly ever the case especially with the latter), the lifecycle of your SAM may be affected.
• Group-to-role mapping is not covered as it's container-specific.
• I included comments wherever I felt like doing so. Not all are (completely) useless. Aided by the spec, the code should be comprehensible --but feel free to ask if something's troubling you. Apologies for the overlength post.
• Paths are absolute from the root of a standard Maven project. Once you've adapted the properties and/or authentication / group retrieval methods in the SAMs, you can build all files as a WAR and deploy the latter on your AS as-is to test it. The sole dependency is that of (provided) javaee-api 7.0 (plus your JDBC driver, unless already present on the AS class path).
• I had to move the code to a Gist due to SO's post length constraint.

1. ServletContextListener 注册 AuthConfigProvider 。保存为 /< project> /src/main/java/org/my/foosoft/authn/BigJaspicFactoryRegistrar.java 。


2. AuthConfigProvider 。保存为 /< project> /src/main/java/org/my/foosoft/authn/BigJaspicFactory.java 。


3. ServerAuthConfig 。保存为 /< project> /src/main/java/org/my/foosoft/authn/LittleJaspicServerFactory.java 。


4. 基本双重 ServerAuthContext - ServerAuthModule 实现帮助程序类。这是实际答案的1/3。保存为 /< project> /src/main/java/org/my/foosoft/authn/HttpServletSam.java 。


5. 独立SAM 实施。实际答案，第2/3部分。另存为 /< project> /src/main/java/org/my/foosoft/authn/StandaloneLdapSam.java 。


6. JAAS LM委派SAM 。实际答案，第3/3部分。保存为 /< project> /src/main/java/org/my/foosoft/authn/JaasDelegatingLdapSam.java 。


7. 方便例外类型。保存为 /< project> /src/main/java/org/my/foosoft/authn/JaspicMischief.java 。


8. 随附的 属性 。如果您想逐字测试实际的身份验证代码，请根据您的需要调整它们。保存为 /< project> /src/main/resources/org/my/foosoft/authn/jaspic-provider.properties 。


9. 随附示例 login.conf 代码段（6）;请参阅供应商的文档，了解实际的文件系统位置。


10. /< project> /src/main/java/org/my/foosoft/presentation/UserUtils.java （可选 - 用于演示目的： JSF支持bean ）


11. /< project> /src/main/webapp/index.xhtml （可选 - 用于演示目的：< a href =https://gist.github.com/anonymous/ab768e6d51779001b125#file-index-xhtml\"rel =nofollow noreferrer>不受保护的索引页面）


12. /< project> /src/main/webapp/login.xhtml （可选 - 用于演示目的：登录页面）


13. /< project> / src / main /webapp/restricted/info.xhtml （可选 - 用于演示目的：受保护的索引页，用于角色 access_restricted_pa​​ges ）


14. /< project> /src/main/webapp/WEB-INF/web.xml （可选 - 用于演示目的和为了完整性：网络模块DD ）

1. The ServletContextListener registering the AuthConfigProvider. Save as /<project>/src/main/java/org/my/foosoft/authn/BigJaspicFactoryRegistrar.java.
2. The AuthConfigProvider. Save as /<project>/src/main/java/org/my/foosoft/authn/BigJaspicFactory.java.
3. The ServerAuthConfig. Save as /<project>/src/main/java/org/my/foosoft/authn/LittleJaspicServerFactory.java.
4. The base dual ServerAuthContext - ServerAuthModule implementation helper class. This is part 1/3 of the actual answer. Save as /<project>/src/main/java/org/my/foosoft/authn/HttpServletSam.java.
5. The standalone SAM implementation. Actual answer, part 2/3. Save as /<project>/src/main/java/org/my/foosoft/authn/StandaloneLdapSam.java.
6. The JAAS LM-delegating SAM. Actual answer, part 3/3. Save as /<project>/src/main/java/org/my/foosoft/authn/JaasDelegatingLdapSam.java.
7. Convenience exception type. Save as /<project>/src/main/java/org/my/foosoft/authn/JaspicMischief.java.
8. The accompanying Properties. Adapt them to your needs if you'd like to test the actual authentication code verbatim. Save as /<project>/src/main/resources/org/my/foosoft/authn/jaspic-provider.properties.
9. Accompanying sample login.conf snippet for (6); consult vendor's documentation for actual file system location.
10. /<project>/src/main/java/org/my/foosoft/presentation/UserUtils.java (optional - for demonstration purposes: JSF backing bean)
11. /<project>/src/main/webapp/index.xhtml (optional - for demonstration purposes: unprotected index page)
12. /<project>/src/main/webapp/login.xhtml (optional - for demonstration purposes: login page)
13. /<project>/src/main/webapp/restricted/info.xhtml (optional - for demonstration purposes: protected index page for users in role access_restricted_pages)
14. /<project>/src/main/webapp/WEB-INF/web.xml (optional - for demonstration purposes and for the sake of completness: web module DD)

---

进一步阅读：

---

Further reading:

1. JSR-196（JASPIC）规范


2. Arjan Tijms的 JASPIC ZEEF页面


3. JSR-115（JACC）规范

1. JSR-196 (JASPIC) Specification
2. Arjan Tijms's JASPIC ZEEF page
3. JSR-115 (JACC) Specification

---

¹ JASPIC非常棒理论上，通用SPI能够在插入有能力的消息处理运行时时对JMS，SAML-over-SOAP和任何其他类型的消息进行身份验证。即使其主要使用的 Servlet容器配置文件也不会过度约束它。

---

¹ JASPIC is very a generic SPI, in theory able to authenticate JMS, SAML-over-SOAP and any other kind of message, when plugged into a capable message processing runtime. Even its predominantly used Servlet Container Profile does not overly constrain it.

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

JASPIC's low-level, flexible nature entails unawareness of protocol-specific functionality, such as the HTTP session. Consequently, ServerAuthContexts / SAMs are triggered by the runtime to perform authentication on every request.

然而规范使得通过允许SAM通过 MessageInfo 回调属性 c> 回调属性来请求运行时启动容器认证会话，从而提供有关此潜在缺陷的规定/ em>的。当被要求验证同一客户端的后续请求时，SAM可以通过要求运行时重用先前建立的AS身份验证会话来避免重复整个过程，因此用户身份（呼叫者和/或组 Principal （S））。这是通过执行示例代码的 HttpServletSam 中显示的do-nothing- / leave-authentication-state-as-is-protocol来完成的。

The spec however makes a provision about this potential shortcoming by allowing SAMs to request initiation of a container authentication session by the runtime, via a MessageInfo Callback Property. When asked to authenticate subsequent requests of the same client, SAMs can avoid repeating the entire process, by asking the runtime to reuse the previously established AS authentication session, hence the user identity (caller and/or group Principal(s)). That is accomplished via execution of the "do-nothing-/leave-authentication-state-as-is-protocol" shown in the HttpServletSam of the sample code.

最后应该注意的是，JASPIC和Servlet规范都没有明确定义容器认证会话是什么。对于SAM认证用户，出于所有实际目的，我会认为AS认证会话等同于HTTP会话，只要a）认证属于单个应用程序上下文并且b）SAM，如上所述，表示在每个请求上重用AS认证会话。

It should lastly be noted that neither the JASPIC nor the Servlet spec clearly defines what a container authentication session is. For a SAM-authenticated user I would, for all practical purposes, consider the AS authentication session to be the equivalent of the HTTP session, as long as a) authentication pertains to a single application context and b) the SAM, as explained above, signals reuse of the AS authentication session on each request.

这篇关于挂起容器请求LDAP用户角色的进程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！