做 PLM 集成的老哥们应该都有这种体会企业上了一套 Agile PLM尤其是 9.3.6 这个版本之后业务部门刚开始还挺兴奋但用不了多久抱怨就集中到账号和登录上面了——设计、工艺、采购、质量各干各的手里攒着四五套系统的密码每天光登录就能把人逼疯。我参与过好几个 Agile 9.3.6 的项目几乎每个客户到最后都会提同一个需求能不能让我们从 OA 里点一下就直接进 PLM能不能别让我们再记一遍账号密码这个需求放到技术上就是单点登录。Oracle Agile PLM 9.3.6 本身是一个 Java EE 应用默认跑在 WebLogic 上它的认证体系既支持自带的数据库用户也支持对接 LDAP/AD但要做到“一次登录、处处访问”光靠 Agile 自身的用户管理是不够的必须在应用前面再架一层统一的认证入口。这篇内容我就把自己在 Agile 9.3.6 上做单点登录配置的完整思路、实施步骤和踩过的坑整理出来主要面向做企业应用集成的实施顾问、运维工程师以及正在被 PLM 登录问题折磨的项目经理。1. 先搞清楚 Agile 的认证链路再动手1.1 Agile 935/936 常见的认证路径很多第一次做 Agile SSO 的人上来就翻配置文件这是误区。Agile PLM 9.3.6 的认证不是一个简单的“用户名 密码”校验它是分层的。默认情况下用户在浏览器里打开 Agile Web 客户端输入账号密码后请求会先到达 Web 应用层BPM、Agile Web Services 这些组件都跑在同一个 Web 容器里然后由 Agile 的安全模块去查询用户存储。用户存储可以是 Agile 自带的数据库表也可以是外部目录服务。如果我们把用户源切到 AD 或 LDAPAgile 会通过 JNDI 去目录服务器做 bind 校验。这个路径的特点是Agile 直接参与了密码校验SSO 并没有真正建立起来。用户依然要在 Agile 登录页面输入账号密码只不过密码的校验方从数据库变成了目录服务。真正的单点登录要的是“用户根本不需要在 Agile 页面输入任何凭据”。9.3.6 版本在架构上支持的 SSO 方式核心思路是在 Agile 应用的前面加一个认证代理由代理负责和统一身份平台打交道校验通过后再把“可信用户身份”传递给 Agile。Agile 本身要配置成信任这个代理。如果这一点没有想清楚后面所有配置都会绕圈子。1.2 三种落地方式怎么选我在项目里实际接触过的 Agile 936 SSO 方案大体可以分成三条路。第一条路是 Oracle 全家桶式的正面集成典型代表是 OAMOracle Access Manager加 OID/OUD。Agile 官方文档里有专门的集成指南支持通过 OAM 做 Web SSOAgile 侧通过 WebGate 或自定义登录模块来接入。这条路的好处是和 Oracle 体系贴合最紧密官方支持力度大后续版本升级不容易出问题。坏处是部署成本高一套 OAM 环境下来域名、WebGate、策略配置都要折腾如果企业身份平台不是 Oracle 系反而增加运维负担。第二条路是 CAS 统一认证。CAS 在 Java 生态里太通用了很多企业的 OA、ERP 都已经接了 CAS。Agile 要接 CAS本质上是在 Agile 的 Web 层加一个 CAS 客户端过滤器把未认证的请求重定向到 CAS Server拿到 ticket 后换取用户身份。这条路的好处是灵活、跨平台适合异构环境坏处是需要动 Agile 的 web.xml、打包自定义过滤器对实施人员的 Java Web 功底有要求。第三条路我称之为“轻量改造”也是我在几个项目里最终落地的方案在 Agile 前面挂反向代理Nginx 或 WebGate统一认证网关在完成用户认证后把用户名写入 HTTP 请求头Agile 侧通过自定义过滤器读取请求头中的用户名直接建立会话。这个方案最适合已经有统一身份网关、又不想上 OAM 的企业。它的核心逻辑是“外部认证内部信任”实现起来最快但前提是网络边界要干净不能让外部请求直接绕过网关触达 Agile。三者的取舍我整理了一个表格供参考方案部署复杂度与 Oracle 体系契合度适合场景主要风险OAM 集成高高企业身份平台已基于 Oracle组件多、策略配置复杂CAS 客户端中中异构系统多、已有 CAS需改 Agile 部署包反向代理 Header低中已有统一认证网关/门户安全边界依赖网关2. 动手前的前置准备别等配置到一半才发现缺东西2.1 版本与补丁环境核对SSO 配置看似是个功能开关实际上牵一发动全身。我在项目里踩过的第一个坑就是对 Agile 9.3.6 的部署环境了解不够导致配置过程中反复重启应用还把 WebLogic 域搞坏过一次。这里必须先做几项环境核对。第一确认 Agile 的补丁级别。Agile 9.3.6 发布后Oracle 出过很多累积补丁其中一部分直接修复了 SSO 相关的问题尤其是和 WebLogic 版本兼容性相关的缺陷。不要在一个老旧补丁级别上直接做 SSO 配置建议先把补丁升到当前项目适用且经过验证的版本再动手。补丁升级本身也有风险所以在测试环境先做一次补丁升级演练比在配置 SSO 过程中发现基础环境有问题要划算得多。第二核对 WebLogic 的版本和模式。Agile 936 支持 WebLogic 12c 的特定版本SSO 配置里涉及的安全声明、过滤器顺序、ClassLoader 加载方式都跟 WebLogic 的部署结构相关。如果你发现 Agile 应用目录下修改了 class 文件但总是不生效十有八九是 WebLogic 的缓存机制在作怪这时候需要清理 domains 下的 tmp 和 cache 目录再重启。第三检查数据库连接状态。Agile 的 SSO 配置虽然不直接改数据库表但 Agile 应用启动时要访问 Agile 数据库中的用户和组信息。我记得有一次项目里配置完 SSO 后应用无法启动日志里报的是数据库连接异常查了半天才发现是应用服务器和数据库之间的网络策略变动跟 SSO 配置半毛钱关系都没有。所以动手前先确认 Agile 的应用数据库连接、监听服务都正常能省掉后面大量的排查时间。如果这时候你正好遇上 Oracle 监听服务无法启动或者 ORA-28547 这种连接错误先把基础环境修复再谈 SSO。2.2 账号映射、域名与证书规划SSO 配置最大的工作量往往不在技术而在账号和域名的规划。Agile 里的用户账号和统一身份平台里的用户账号通常不是同一个体系。举例来说统一身份平台里用户的登录名可能是工号或者邮箱前缀而 Agile 里的 User ID 可能是人名拼音加部门后缀。要让 SSO 生效必须在两者之间建立映射关系。我建议在配置前就理清楚三个问题。第一Agile 用户源是使用内置数据库用户还是已经切到了外部目录服务如果还在内置用户阶段SSO 过程中获取到的外部用户名必须能在 Agile 用户表中找到对应记录否则即使认证通过Agile 也不认这个人。第二有没有一个稳定的用户标识可以作为映射键我最推荐的是邮箱地址或员工工号尽量避免用中文姓名或职位作为唯一标识。第三后续的新员工入职、离职流程中账号由谁来同步如果身份平台和 Agile 之间的用户数据没有自动同步机制纯靠手工维护时间一长肯定会出现“SSO 通过了但 Agile 没这个人”的尴尬情况。域名和证书规划同样重要。Agile 的 Web 应用域名、SSO 认证服务器的域名必须提前确定。二者不能是跨域且不考虑 Cookie 作用域否则登录态很难维持。我见过一个项目SSO 服务器域名是sso.company.comAgile 是plm.company.com两边主域名一致Cookie 配置相对容易另一个项目 Agile 用了plm.company.com.cn认证服务器是sso.company.com主域名不一致Cookie 无法跨域传递方案直接被推翻重来。另外Agile 936 的 SSO 配置强烈建议走 HTTPS因为用户名通过请求头或 Cookie 传递时如果是明文 HTTP抓包就能看到用户身份这等于把系统大门敞开了。所以证书申请、HTTPS 终结位置是在 Web 层终结还是透传到应用层都要提前规划。3. 配置实操按层拆解一步一步来3.1 认证服务端准备不管采用哪种 SSO 方案认证服务端的工作都绕不开两件事一是让 Agile 成为合法的接入应用二是把用户身份安全地传递给 Agile。我以最常见的 CAS 和 OAM 两种方式为例把服务端配置的关键点分别讲一下。如果走 CAS需要登录 CAS 管理后台把 Agile 的 Service 地址注册进去。Service 地址就是用户完成 CAS 认证后会被重定向回来的 Agile 页面地址一般形如https://plm.company.com/Agile/PLMServlet。这个地址一定要写准不能带多余的路径参数也不能有大小写错误否则 CAS 会认为这个 Service 未注册而拒绝放行。同时需要在 CAS 的 Service Registry 里配置允许的属性返回一般至少要把用户名或用户唯一标识返回给 Agile。如果你希望 Agile 侧能拿到更多信息比如邮箱、部门也可以在 CAS 的 Attribute Release 策略里配置但不要贪多Agile 真正需要的只是一个可靠的用户名。如果走 OAM需要在 OAM 中创建 Agile 对应的受保护资源并将认证策略设置为 “需要认证”。同时要配置 OAM 的 WebGate 或代理指定它保护 Agile 的哪个虚拟路径。注意Agile 的部分免登录访问路径比如健康检查、公共接口要在 OAM 中显式排除掉否则系统监控和外部系统回调会全部被拦截在 SSO 外面。无论是 CAS 还是 OAM服务端配置完成后都要先手动在浏览器里验证一下“认证服务器本身能正常登录并返回用户信息”再进入 Agile 侧的配置。不要等服务端和客户端都改完再一起联调那样问题定位会非常困难。3.2 Agile 应用端核心调整Agile 应用端的调整是整个配置里最考验耐心的一环也是最容易出现“配置不生效”的地方。先说最容易理解的部分Agile 的登录页面要跳过。默认情况下未认证用户访问 Agile 会被重定向到登录页面SSO 要做的事就是把这一步替换掉让请求直接进入认证流程。以 CAS 客户端方案为例需要在 Agile 的 Web 应用描述文件web.xml中添加一个认证过滤器将过滤器映射到需要保护的 URL 上通常是/Agile/*。过滤器在用户请求到达 Agile 业务逻辑之前先检查本地会话中是否有认证标记如果没有就把请求重定向到 CAS 的登录地址并带上 Service 参数。CAS 认证通过后会重定向回 Agile过滤器再拿 ticket 去 CAS 验证验证通过则创建本地会话。这一段逻辑说起来简单实际配置时有两个非常容易踩的细节。第一个细节是过滤器的执行顺序。Agile 自带的 Session 管理机制会在请求进入业务逻辑之前处理会话信息如果 SSO 过滤器配置在它之后那么 SSO 会话创建完成后Agile 的原有会话机制可能还没来得及初始化导致页面加载后又弹回登录页。正确的做法是把 SSO 过滤器的执行顺序放在最前面保证在 Agile 业务代码运行之前当前用户身份就已经被确认。第二个细节是登录退出。用户从 Agile 点退出时Web 应用层只销毁了本地会话CAS 或 OAM 里的全局会话依然有效。如果用户紧接着再次访问 AgileSSO 过滤器看到认证服务器还有有效会话会直接放行用户感觉“退出失败”。这个问题的处理需要在退出 URL 上拼接认证服务器的注销地址同时销毁全局会话和本地会话。如果采用反向代理 Header 的方案Agile 侧的调整相对集中同样是在web.xml中加过滤器但这个过滤器不做重定向也不验证 ticket它只做一件事——从 HTTP 请求头中取出代理注入的用户名然后调用 Agile 的登录接口建立本地会话。这里最关键的配置是必须保证外部请求无法伪造请求头。代理层在转发请求给 Agile 之前要把从客户端接收到的同名请求头清空再写入可信的用户名。我在一个项目里见过因为代理配置疏忽导致用户可以通过浏览器插件私自添加请求头来冒充别人的身份这是极其严重的安全漏洞。所以请求头的名字要起得冷门一些代理层的清洗逻辑必须在测试环境反复验证确认从公网访问时该请求头不可能被客户端自定义传入。3.3 网关与代理层透传配置网关和代理层的配置直接决定了 SSO 的用户体验是否顺畅。这里说的代理层可能是企业统一的认证网关也可能是自己部署的 Nginx无论如何核心要解决三个问题透传、超时、静态资源。透传指的是用户身份信息怎么从认证系统传到 Agile。如果走 Header 方案代理层要在用户完成认证后把当前用户信息写入请求头再反向代理到 Agile 的后端地址。这个过程中有两个细节要处理好。一是不要在代理层直接把原始请求头透传而是显式声明哪些头保留、哪些头由代理自己生成。二是 Cookie 的作用域。Agile 和认证系统的会话 Cookie 名称可能会冲突比如都叫JSESSIONID代理层最好给后端 Agile 的 Cookie 做一个重命名避免前后端会话互相覆盖。超时问题通常被忽略但影响最大。统一认证网关一般有自己的会话超时设置有的默认 30 分钟Agile 自己的会话超时可能是 60 分钟。如果用户在 Agile 上挂了 45 分钟没操作Agile 会话还在但网关会话已经超时了用户下一次点击页面上的任意功能请求到网关层被判定为未认证被重定向到登录页用户刚才填的内容全部丢失。这种问题很隐蔽排查看上去像是 Agile 的问题实际上是网关和 Agile 的会话超时策略不一致。建议把两边的会话超时统一或者至少保证网关超时时间不小于 Agile 的超时时间。静态资源的放行规则也要在代理层提前设置好。Agile 的页面会加载很多静态文件JS、CSS、图片这些文件的请求不应该触发 SSO 重定向否则页面加载时静默请求被重定向到登录页白白增加网络开销极端情况下还会因为重定向链太长直接报错。在代理层或认证服务器中把/Agile/designrepository,/Agile/extension,/Agile/common,/Agile/images这类静态资源路径列入免认证名单是常规做法。4. 调试、排查与回滚实操4.1 日志怎么看、验证怎么测SSO 配置完成后最怕的就是“登录不进去”和“登录进去了但 Agile 不认”。这类问题靠肉眼是看不出来的必须通过日志来定位。Agile 侧的日志主要有三个来源。第一个是 WebLogic 的应用日志记录了 Agile 应用启动和运行时的全部输出。SSO 过滤器如果有异常多半会在这里留下堆栈。第二个是 Agile 自己的应用日志目录位置一般在 Agile 安装目录的log文件夹下里面记录了 Agile 业务层的日志包括用户登录成功、失败的原因。第三个是认证服务器侧的日志CAS 有cas.logOAM 有 OAM Server 的日志文件从这里能看到每个认证请求的处理结果。排查 SSO 问题时我的习惯是先看认证服务器日志确认用户是否完成了认证再看 Web 层日志确认认证结果有没有正确传递到 Agile最后才看 Agile 应用日志确认 Agile 内部对用户身份的映射是否成功。按这个顺序排查可以快速把问题缩小到某一个环节。我总结了一个验证清单每次做完 SSO 配置至少要把这些场景全部走一遍验证项预期结果检查点未登录直接访问 Agile自动跳转到统一登录页浏览器地址栏 URL 变化输入正确账号密码后登录自动跳转回 Agile 且已登录Agile 页面右上角显示当前用户访问第三方已接入系统后切到 Agile无需再次输入密码跨系统跳转时无登录页出现点击 Agile 退出按钮回到统一登录页或首页本地与全局会话均被清除长期挂机后操作跳转登录但登录后回到原页面是否丢失了用户操作上下文直接 IP 访问 Agile 内网地址被拒绝或要求登录无法绕过认证网关直达应用4.2 高频坑与处理实录做过的项目多了发现 SSO 配置的坑来来去去就那几个我挑几个代表性的写下来给后来人做个参照。第一个坑是循环重定向。用户访问 Agile被重定向到认证服务器认证服务器又给重定向回 Agile来回跳页面一直转圈最后报“重定向过多”。这种情况通常是 Service 地址配置不对认证服务器认为回调地址不是合法来源。排查时先看浏览器地址栏最后的 URL 是什么如果停在认证服务器的地址上说明回调校验失败如果停在 Agile 地址上说明 Agile 侧没有正确完成会话创建。我遇到过一次很隐蔽的情况——CAS 配置的 Service 地址是 HTTPS但 Agile 实际收到的回调请求走的是 HTTP两边协议不一致CAS 直接拒绝。最后在代理层做了 HTTP 到 HTTPS 的强制跳转才解决。第二个坑是用户认证成功但 Agile 里找不到账号。这是账号映射问题。SSO 传过来的用户名是一串工号Agile 用户表里存的是姓名拼音两者对不上Agile 就会当作新用户处理或者直接报“用户不存在”。这里有一个讨巧的处理方式在 Agile 的用户管理中把外部用户单独放到一个组里利用 Agile 的 External Directory 功能在 SSO 过滤器映射用户时按照映射表的规则查询 Agile 用户 ID映射表可以放在配置文件、数据库表或者从身份平台同步过来。务必在配置 SSO 之前就把账号映射核对清楚我就吃过亏上线后发现几百个用户里有一小半映射不对只能一边跑一边改数据。第三个坑是登录成功后跳转的页面不对。用户完成 SSO 登录默认跳到 Agile 的主页但很多用户希望跳到上一次操作的界面或者跳到某个固定的业务首页。Agile 的 URL 通常会带一个 returnUrl 参数SSO 过滤器在完成会话创建后要能识别并处理这个参数。如果不处理用户每次登录都是从头开始使用体验会打折扣。这个功能看起来小但对日常使用的影响非常大。第四个坑是调试过程中修改配置不生效。Agile 的部署结构比较特殊改了 class 或配置文件后不是简单重启就完事很可能需要清理 WebLogic 的缓存目录。我在改造 SSO 过滤器时有几次明明把新编译的 class 包放上去了重启后却还在执行旧逻辑排查了半天才发现是 tmp 目录下的旧 class 被重新加载了。后面我养成了一个习惯每次更新部署相关文件后先把$DOMAIN_HOME/servers/AdminServer/tmp和cache目录清掉再重启一步到位。第五个坑是 HTTPS 证书问题。SSO 交互中Agile 需要向认证服务器发起请求验证票据如果认证服务器的 SSL 证书不是由可信 CA 签发测试环境最常见的坑Java 的信任库会直接报 SSL 握手异常认证请求静默失败。处理方式是把认证服务器的根证书导入到 Agile 应用服务器 JVM 的cacerts信任库中。但注意导入后要重启应用服务器而且不同 JDK 版本导入路径和命令格式略有差异建议在测试环境先练一遍。5. 回滚方案与上线节奏控制SSO 上线是有风险的企业用户量大一旦登录出现大规模问题影响面非常广。所以每次做 SSO 上线我都会准备一套完整的回滚方案并且把上线节奏拆得很细。回滚方案的核心是保存好配置变更前的完整备份。Agile 侧的备份点主要有三个一是web.xml等 Web 应用配置文件的原始版本二是 Agile 安装目录下涉及身份认证的相关配置文件夹三是 WebLogic 域配置。每一次变更操作落地之前先把这些文件的当前状态做快照记录时间和操作人。如果上线后发现问题恢复这些文件并重启应用就能回到变更前的状态。同时认证服务器侧的 Service 注册记录也要保留以便随时注销 Agile 这个接入应用。上线节奏上我强烈建议分步放量。第一步先在测试环境完整验证所有功能场景包括正常登录、退出、超时、多系统互跳。第二步在生产环境挑选一个用户组或一个部门作为试点通过 URL 定向或账号白名单的方式只让试点用户走 SSO 通道。第三步试点运行一到两周收集用户反馈确认没有明显问题后再全量切换。全量切换最好放在业务低峰期比如周五晚上留出周末两天的缓冲时间。另外SSO 切换之后原 Agile 登录页通常不能直接关闭因为系统间集成可能还需要通过账号密码调用 Agile 接口。比如一些后台脚本、报表系统它们不会走浏览器 SSO 流程而是用服务账号直接调用 Agile Web Services。此时需要在 SSO 配置中保留服务账号的后门登录能力否则这些系统会大面积报错。Agile 的 Web Services 认证走了单独的机制一般不受 SSO 过滤器影响但不同的版本和配置方式会有差异这一点要在上线前跟项目里负责系统集成的人确认清楚。6. 配置完成后的运维注意事项SSO 配置完成、上线稳定之后不代表就一劳永逸了。我在项目运维支持阶段总结了几条长期需要注意的事项分享出来供大家参考。第一定期检查认证服务器和 Agile 之间的会话超时配置。企业信息安全策略调整时经常会对全局会话超时做改动一旦认证服务器的超时时间被调短用户在使用 Agile 时会频繁掉线体验非常差。建议把两边的超时时间配置纳入变更管理每次修改都要联动检查。第二用户账号的生命周期同步。SSO 打通后新员工入职、员工离职、岗位调动这几个场景必须有明确的操作规程。离职员工如果在 Agile 中还有启用状态的账号即使他访问不了 SSO 入口也仍然是一个安全隐患新员工如果在统一平台里有账号但 Agile 里没有他第一次访问 SSO 后也无法进入 Agile 系统。这个同步机制可以靠定时任务做也可以在统一身份平台里配置人力资源系统的联动总之不能纯靠手工。第三监控 SSO 的认证成功率。我习惯在认证服务器和 Agile 各放一条监控统计每天的认证请求量、成功率、响应时间。SSO 链路涉及的组件多任何一个环节出问题用户都会被挡在门外。设计合理的监控可以第一时间发现问题而不是等业务部门的投诉电话打过来。第四保留手工登录的应急通道。SSO 服务再稳定也架不住认证服务器宕机、网络策略误改这类意外。在 Agile 侧保留一个不经过 SSO 的应急登录入口比如通过特定的管理 URL 使用本地账号登录至少能让管理员在紧急情况下进入系统处理问题不至于整个 PLM 彻底失联。我在实际操作中的体会是Agile 936 的单点登录配置真正难的不是技术实现而是对系统整体架构和业务账号体系的把控。技术上无非是过滤器和重定向那几板斧但每个企业的账号体系、域名规划、安全策略都不一样一个小细节考虑不到位就会在上线时给你当头一棒。如果你是第一次接这类项目我建议先小范围试点同时务必把回滚方案准备扎实——有时候最快的排障手段就是把改动撤销。等你经历过一轮完整的配置和上线后面再做类似的 SSO 项目就会从容很多。