Tomcat部署Java Web应用集成OKTA单点登录(SSO)方案咨询

前置准备 #

• Okta租户管理员权限
• Java Web应用源码访问权限、Tomcat服务操作权限
• 确认应用用户体系可与Okta用户属性（邮箱、用户ID、角色等）完成映射

Okta管理端配置 #

1. 登录Okta管理后台，进入应用管理板块，选择新建SAML 2.0类型的应用集成，填写应用名称、图标等基础信息后进入参数配置页
2. 填写核心SAML配置项：
   • 单点登录URL（ACS地址）：填写应用接收Okta SAML断言的服务地址，示例格式为https://你的应用域名/访问路径/saml/acs
   • Audience URI（SP实体ID）：自定义应用唯一标识，后续应用端配置需和该值完全一致
   • Name ID格式按需选择，一般选EmailAddress，对应值选择Okta用户的邮箱属性
3. 配置属性映射：添加需要透传给应用的用户属性，比如姓名、角色、部门等，字段名需和应用现有登录逻辑依赖的用户字段匹配
4. 配置完成后保存应用，进入分配标签页，给需要访问应用的用户/用户组开通该应用的访问权限
5. 从应用的SAML配置页导出/复制三个核心参数备用：IdP实体ID、Okta单点登录地址、SAML签名证书

Java应用端改造 #

依赖引入 #

如果是Maven项目，直接从Maven中央仓库引入Okta官方SAML Java SDK的最新稳定版依赖；非Maven项目手动导入对应Jar包到WEB-INF/lib目录即可。

核心逻辑调整 #

1. 在应用配置文件中新增以下配置项，填入之前从Okta端获取的参数：
   • IdP实体ID、Okta单点登录地址、SAML签名证书
   • 自定义的SP实体ID、ACS地址
2. 新增ACS接口：开发对应ACS地址的接口，用于接收Okta返回的SAML Response
3. 断言校验逻辑：对接收到的SAML Response做签名校验、有效期校验，校验通过后解析出用户属性、角色信息
4. 适配现有登录逻辑：将解析得到的用户信息按应用原有规则生成登录态，写入会话或者Cookie
5. 替换拦截逻辑：删除原有Keycloak相关的校验逻辑，调整全局访问拦截规则，未携带有效登录态的请求直接重定向到Okta单点登录地址

部署验证 #

将修改后的代码重新打包为WAR包，上传到Tomcat的webapps目录，重启Tomcat服务后测试：

• 访问应用地址是否自动跳转到Okta登录页
• 输入合法用户账号密码登录后是否能正常跳转回应用并访问受保护资源
• 验证用户角色、权限是否和Okta侧配置一致

常见问题排查 #

• 跳转到Okta提示请求无效：检查SP实体ID、ACS地址是否和Okta端配置完全一致，无拼写错误或路径偏差
• SAML Response校验失败：检查SAML签名证书是否配置正确，服务器系统时间是否和标准时间同步（误差超过5分钟会导致有效期校验失败）
• 登录成功后应用提示无权限：检查Okta侧属性映射配置的字段名、字段值是否和应用预期匹配

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