Fatal编程技术网
  • java/
  • Java 钩住容器请求LDAP用户角色的过程

Java 钩住容器请求LDAP用户角色的过程

java security jakarta-ee ldap

Java 钩住容器请求LDAP用户角色的过程,java,security,jakarta-ee,ldap,Java,Security,Jakarta Ee,Ldap,在我的应用程序中，我使用LDAP域的基于表单的身份验证。对于授权，我使用数据库。据我所知，这项工作如下 App --> (user, pass) --> LDAP <-- OK, user exists -- --> ask for security roles for 'user' --> JACC / Database <-- Administrator -- App--

在我的应用程序中，我使用LDAP域的基于表单的身份验证。对于授权，我使用数据库。据我所知，这项工作如下

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

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

App-->（用户，通行证）-->LDAP
请求“用户”的安全角色-->JACC/Database

您可以使用Spring Security对其进行自定义，根据LDAP进行身份验证，并配置身份验证管理器/身份验证提供程序：


<security:authentication-manager>
    <security:authentication-provider user-service-ref="userDetailsService">
        <security:jdbc-user-service data-source-ref="dataSource"                    
            authorities-by-username-query="select AUTHORITIES.AUTHORITIES_AUTH from AUTHORITIES, USERS where AUTHORITIES.AUTHORITIES_USER_ID = USERS.USERS_ID and ..."/>



TL；DR：查看并获取一个样本溶液。



您的要求取决于您使用的特定于供应商的功能所提供的灵活性程度；您的产品可能允许也可能不允许您扩展该/这些
LoginModule
/
领域的行为
/
IdentityStore
/无论它是什么/它们被称为专有类，或者甚至可能只在某个管理UI的输入字段中键入SQL查询。底线是它是非标准功能

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

我将在这篇文章中包括一个基于JASPIC的解决方案，并且在很大程度上忽略JACC，因为：


    

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

  • 使用自定义JACC提供程序解决方案需要而且仍然不是100%标准，因为它是特定的组到角色映射
    • 

  • 我不知道有一个开源项目使用定制的JACC提供者来完成一些有意义的事情；Java EE完整概要文件实现AS是唯一的例外，因为他们被授权实现规范，有时也在内部使用JACC提供程序（例如GlassFish）
    • 

  • JASPIC是两个规范中最简单的一个，但它仍然存在很多困惑（许多开发人员甚至不知道它的存在）。在继续报道JACC之前，首先让更多的人知道JASPIC并“接近”它是非常合理的
    • 

  • 虽然现在在JASPIC online上有不止几个很好的例子，通过JASPIC提供商实现实际身份验证的项目也是如此，-如果我错了，请纠正我-我还没有找到完整的JASPIC例子
    • 


以下是一些评论：


    

  • 无保修/自担风险使用/如果您的应用程序/AS/系统爆炸或被外星人/等攻击，请不要起诉我
    • 

  • 请试着忽略那些你认为优化、更好的设计或其他改进至关重要的地方。是的，您可以承认重用DB/LDAP连接；验证插入LDAP搜索筛选器的用户名；更加关注线程安全；使用TLS；对于格式不正确的XML有效负载，返回400。解决这些问题超出了所提供解决方案的范围。打扰一下你想知道单元测试在哪里？？？！对不起，从来没听说过这个词！：）

  • 提供了两个SAM，具体执行组（角色）的身份验证和检索：一个“独立”，它自己完成两个任务；另一个“委托”SAM，顾名思义，它演示了SAM如何通过使用JASPIC LoginModule桥接配置文件将实际的身份验证工作委托给JAAS（LM）。后一种SAM需要进一步的配置/调整，包括AS和源级别本身，除非您使用的是GlassFish。提供了一个附带的JAAS
    login.conf
    条目示例
    • 

  • 提供程序类根据GlassFish 4.1进行了测试。他们努力保持规范的一致性，因此也应该在您的AS上工作（显然，第二个SAM除外），前提是您的产品实现了完整的JavaEE（6，最好是7）概要文件。如果没有，我很抱歉；不，我不会测试你的AS
    • 

  • 您可以避免研究/使用和实现，但随后必须以专有方式（通过特定于供应商的
    foo web.xml
    和/或进一步使用部署/管理工具）向您的产品注册实际SAM。此外，您将不会让SAM实现接口，并且必须从SAM中加载附带的
    属性
    。您的AS将为您实例化缺少的类，可能会重用“全局”
    AuthConfigProvider
    和/或
    ServerAuthConfig
    已为所有应用程序和消息层预先配置。请注意，根据它是否跨请求重用其实例化的
    ServerAuthConfig
    和
    ServerAuthContext
    （尤其是后者），SAM的生命周期可能会受到影响
    • 

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

  • 我喜欢在任何地方发表评论。不是所有的都（完全）无用。在规范的帮助下，代码应该是可理解的——但请随意询问是否有什么问题困扰您。为过长的邮件道歉
    • 

  • 路径是从标准Maven项目的根开始的绝对路径。调整SAMs中的属性和/或身份验证/组检索方法后，可以构建