本文详解 open liberty 中“用户未被授予所需角色”（如 `admin`）的典型授权失败问题，核心原因常是应用名不一致导致安全角色绑定失效，并提供完整配置修正与验证步骤。
在 Open Liberty 应用开发中，当遇到类似以下错误日志时：
CWWKS9104A: Authorization failed for user bob while invoking ServletsJspExperiments on /admin. The user is not granted access to any of the required roles: [admin].
表面看是权限配置问题，但根本原因往往更隐蔽——应用标识不一致。正如案例所示，错误日志中明确提到应用名为 ServletsJspExperiments，而 server.xml 中实际部署的 WAR 文件却是 ServletExperiments.war（缺少 Jsp），导致 Liberty 无法将 application-bnd> 中定义的安全角色映射到正确的应用上下文。
✅ 正确配置的关键：三处名称必须严格一致
| 配置位置 | 示例值 | 说明 |
|---|---|---|
| Maven pom.xml | 构建生成的 WAR 文件名（默认为 ${artifactId}.war） | |
| server.xml | 必须与构建输出的 WAR 文件名完全匹配 | |
| 应用内安全注解/web.xml | @HttpConstraint(rolesAllowed = {"admin"}) + |
定义受保护资源所需的逻辑角色名 |
⚠️ 注意：Open Liberty 的 是按 WAR 文件名（而非 contextRoot）绑定安全角色的。若 location 值与实际 WAR 名不一致，整个 配置将被忽略，用户即使认证成功，也无法获得任何角色授权。
? 修复步骤（以本例为准）
-
统一 WAR 文件名
修改 server.xml，确保与 Maven 构建输出一致： ❌ 错误示例（原配置）：location="ServletExperiments.war" → Liberty 找不到该应用的绑定配置。
-
确认 basicRegistry 已启用且无冲突
确保 server.xml 中已启用 appSecurity-4.0 特性，并正确包含 userRegistry.xml：appSecurity-4.0 -
验证 web.xml 角色声明完整性（可选但推荐）
虽然 Jakarta EE 8+ 支持纯注解式安全，但混合使用时需保证 web.xml 中的与代码中引用的角色名一致： admin
? 验证是否生效
重启服务器后，访问 /admin 并登录 bob 用户，检查日志是否出现：
CWWKS2104I: The authorization decision [...] will be made by using the group names of the user...
且不再报 CWWKS9104A 错误。同时可在 AdminServlet 中添加调试输出：
System.out.println("User: " + securityContext.getCallerPrincipal().getName());
System.out.println("In admin role? " + securityContext.isCallerInRole("admin"));? 补充说明
- 不要混淆 contextRoot 和应用名：contextRoot="/myapp" 仅影响 URL 路径前缀（如 https://host/myapp/admin），不影响安全绑定。
- @FormAuthenticationMechanismDefinition 是认证机制，不负责授权：它只控制登录流程；角色授权由 @ServletSecurity + server.xml/web.xml 联合决定。
- 若使用 microProfile 安全（如 @RolesAllowed），需额外启用 mpJwt-1.2 或 mpOpenAPI-3.1 等特性，并配置 IdentityStore —— 本例使用的是传统 basicRegistry，无需额外配置。
通过确保应用标识（WAR 文件名）在构建、部署、安全绑定三处完全一致，即可彻底解决此类“用户已登录却无权限”的典型授权故障。
