JBoss EAP7.3 Elytron结合FORM认证的程序化登录实现问题

问题背景 #

• 部署环境：JBoss EAP 7.3.6 + Struts2 Web应用，正从旧安全（legacy security）子系统迁移至Elytron安全体系，需支持两种认证模式：
  • 手动FORM认证：用户在登录表单输入凭证提交至j_security_check完成登录，当前Elytron配置下运行正常。
  • JWT Cookie程序化认证：访问受保护资源的GET请求携带包含JWT令牌的自定义Cookie，通过io.undertow.servlet.ServletExtension注册的io.undertow.server.HttpHandler拦截请求；该拦截器在handleRequest方法中提取、预校验JWT并解析出用户名，随后将用户名与JWT作为凭证调用javax.servlet.http.HttpServletRequest#login完成程序化登录。

异常现象 #

• 旧安全子系统下，调用login会自动触发旧安全域认证流程，在Undertow中创建会话，200响应携带新JSESSIONID的Set-Cookie头。
• 切换至Elytron后，直接调用login无任何效果：既不触发Elytron安全域与Realm的认证流程，也不创建会话，浏览器直接跳转至登录表单，跳过预期的拦截登录流程。
• 调试发现：Elytron对应的org.wildfly.elytron.web.undertow.server.SecurityContextImpl的login方法首先校验httpAuthenticator是否为null，该对象仅在调用SecurityContextImpl#authenticate（即javax.servlet.http.HttpServletRequest#authenticate）时才会初始化。
• 尝试先调用authenticate初始化httpAuthenticator再调用login，可触发Elytron安全域的认证与授权流程且认证成功，但Undertow仍不会生成新的JSESSIONID Cookie，浏览器依旧跳转至登录表单而非直接访问受保护资源。

待解答疑问 #

1. 为何Elytron对应的SecurityContext实现与旧安全体系的io.undertow.security.impl.SecurityContextImpl行为差异如此之大？
2. 基于FORM认证的Web应用中，应如何结合Elytron通过HttpServletRequest#login和/或HttpServletRequest#authenticate实现符合预期的程序化登录，使其与旧安全子系统行为保持一致？

现有配置 #

Undertow配置 #

<application-security-domains>
    <application-security-domain name="my_app_security_domain" http-authentication-factory="MyHttpAuthFactory"/>
</application-security-domains>

Elytron配置 #

<security-domains>
    <security-domain name="MySecurityDomain" default-realm="MyCachingRealm" permission-mapper="default-permission-mapper">
        <realm name="MyCachingRealm" role-decoder="FromRolesAttributeDecoder"/>
    </security-domain>
</security-domains>

<security-realms>
    <custom-realm name="MyCustomRealm" module="module name redacted" class-name="class name redacted"/>
    <caching-realm name="MyCachingRealm" realm="MyCustomRealm" maximum-age="300000"/>
    <identity-realm name="local" identity="$local"/>
</security-realms>

<mappers>
    <simple-permission-mapper name="default-permission-mapper" mapping-mode="first">
        <permission-mapping>
            <principal name="anonymous"/>
            <permission-set name="default-permissions"/>
        </permission-mapping>
        <permission-mapping match-all="true">
            <permission-set name="login-permission"/>
            <permission-set name="default-permissions"/>
        </permission-mapping>
    </simple-permission-mapper>
    <constant-realm-mapper name="local" realm-name="local"/>
    <constant-realm-mapper name="MyRealmMapper" realm-name="MyCachingRealm"/>
    <simple-role-decoder name="FromRolesAttributeDecoder" attribute="Roles"/>
</mappers>

<http>
    <http-authentication-factory name="MyHttpAuthFactory" security-domain="MySecurityDomain" http-server-mechanism-factory="global">
        <mechanism-configuration>
            <mechanism mechanism-name="FORM" realm-mapper="MyRealmMapper">
                <mechanism-realm realm-name="MyRealm"/>
            </mechanism>
        </mechanism-configuration>
    </http-authentication-factory>
    <provider-http-server-mechanism-factory name="global"/>
</http>

问题解答 #

疑问1：两种SecurityContext实现行为差异的原因 #

• 旧安全体系的SecurityContextImpl未严格遵循Servlet规范对login的定义，额外实现了无上下文直接触发认证的逻辑，同时默认在认证成功后主动创建会话。
• Elytron的SecurityContextImpl严格遵守Servlet规范：login方法的作用是使用当前已初始化的认证机制校验传入凭证，本身不负责初始化认证上下文。你调试发现的httpAuthenticator为null就是这个逻辑的体现——没有提前走认证初始化流程，login直接跳过。
• 另外Elytron的FORM认证机制采用会话按需创建逻辑：只有当认证流程是由用户主动提交j_security_check触发时，才会自动创建会话并返回JSESSIONID。程序化认证如果没有显式触发生成会话的逻辑，容器不会主动创建Cookie。

疑问2：符合预期的实现方案 #

方案1：调整现有Servlet API调用逻辑（最快适配）

1. 拦截到带JWT的请求后，先调用request.getSession(true)强制创建HttpSession，提前初始化会话上下文，避免后续不生成JSESSIONID。
2. 先调用request.authenticate(response)，哪怕返回false也不影响——这一步只是用来初始化Elytron的httpAuthenticator，构建认证上下文。
3. 再调用request.login(解析得到的用户名, JWT凭证)，此时会用已初始化的FORM认证机制走安全Realm校验。
4. 认证成功后，调用request.changeSessionId()（可选，避免会话固定攻击），此时容器会自动生成Set-Cookie: JSESSIONID=xxx响应头。

方案2：直接用Elytron原生API实现程序化认证（更灵活）

1. 启动时通过JNDI lookup获取绑定到当前应用的MySecurityDomain实例：

   SecurityDomain securityDomain = (SecurityDomain) new InitialContext().lookup("java:/jboss/elytron/security-domain/MySecurityDomain");
   

2. 在JWT拦截器中，用解析到的用户名和JWT作为凭证构建回调，调用securityDomain.authenticate()完成校验，获取已认证的SecurityIdentity。
3. 调用SecurityContextUtil.setIdentity()将身份绑定到当前Undertow请求的SecurityContext，标记认证已完成。
4. 同样提前调用request.getSession(true)创建会话，生成JSESSIONID。

额外配置修正

你当前的Elytron配置存在一处冲突：MyRealmMapper映射的是MyCachingRealm，但FORM机制配置的mechanism-realm名称是MyRealm，两者不匹配可能导致认证后身份关联异常。直接删掉mechanism-realm配置即可，让realm-mapper自动处理Realm路由。

内容的提问来源于stack exchange，提问作者alexfr