一次登录，多个系统通行：从CAS看懂Java老系统的接入与排障

一、多个系统反复登录，问题出在哪里

公司里有报销、考勤、客户管理等几套系统，员工每天都要分别输入账号和密码。系统少时还能忍，数量一多，忘记密码、重复维护账号、离职后权限没有及时回收的问题就会一起冒出来。单点登录解决的正是这类麻烦：用户完成一次身份认证，随后访问接入同一认证体系的应用，可以减少重复登录。

CAS的全称是Central Authentication Service，早期由耶鲁大学开发，是集中认证的一种开源实现。它在Java项目中应用广泛，适合把原先分散的登录入口收拢起来。可以把它理解成企业园区的统一门岗：门岗核实来访者身份，各栋楼再依据自己的规则决定哪些区域允许进入。

落到系统结构上，CAS服务端负责认证，业务应用通过客户端组件接入。用户打开某个应用，应用发现本地没有登录状态，就把浏览器引导到认证中心。登录成功后，浏览器携带票据返回应用，由应用向认证中心校验票据，再建立自己的会话。业务系统由此不必各自接收和核对用户密码。

早期CAS协议的部分校验接口使用XML返回结果，这使不同技术栈之间具备了对接基础，但不能据此认为任意程序都能直接互通。接入方仍要实现重定向、票据验证和会话管理。传统浏览器应用通常更容易接入；桌面客户端或移动应用则需要结合自身交互方式，选择适合的认证协议与客户端方案。

集中认证还带来一个实际好处：密码策略、账号锁定和认证审计可以统一维护。不过，认证中心成为多个应用共同依赖的基础设施后，其故障也会影响登录。因此，上线时除了看功能是否跑通，还要考虑可用性、超时策略和故障恢复，不能只凭一次成功跳转就认定改造完成。

二、沿着一张票据，把登录流程走明白

理解CAS，先分清两种状态：认证中心保存的登录状态，以及业务应用自己的登录状态。前者通常借助认证中心域名下的Cookie维持，后者由各应用分别管理。跨域单点登录主要依赖浏览器跳转和服务端票据校验，并不要求把所有应用的会话Cookie共享出去。

用户登录成功后，认证中心会针对目标服务签发服务票据，常见名称是Service Ticket。浏览器把票据带回应用，应用再通过后端连接请求校验。票据通常具有短时有效、一次性使用、绑定目标服务等约束。应用不能只看到地址里出现ticket参数，就直接认为用户已经通过认证。

跨主机调试时，最容易出问题的是服务地址。浏览器访问的外部地址、应用提交的service参数，以及认证中心登记的服务规则，需要彼此匹配。协议、端口、路径或代理转发配置发生变化，都可能造成校验失败。尤其经过网关后，应用看到的是内部地址，用户看到的却是外部域名，排查时必须把两者对上。

另一个常见障碍是HTTPS信任。浏览器能够打开认证页面，不代表Java进程也信任同一张证书。应用校验票据时使用的是服务端运行环境的信任配置，可以借助keytool检查或维护信任库，同时核对证书链、有效期和主机名。生产环境应正确配置信任关系，不宜靠关闭证书校验解决问题。

实际排障可以按访问应用、跳转认证中心、返回回调地址、后端校验、创建本地会话这条顺序检查。结合浏览器网络面板和服务端日志，通常能很快找到断点。记录时保留时间、请求路径和关联编号即可，密码、完整票据等敏感内容应做脱敏处理，避免调试日志反过来成为泄露入口。

三、登录成功之后，权限还得单独算

CAS负责回答“这个人是谁”，业务系统还要回答“这个人能做什么”。财务人员能审批报销，不代表可以管理服务器；普通员工能查看自己的考勤，也不代表能导出全公司的记录。认证与授权是两个环节，混在一起设计，后续往往会出现权限难维护、职责边界不清的问题。

早期Java项目经常把CAS与Acegi配合使用。Acegi后来演进为Spring Security，因此维护旧工程时，可能同时看到旧框架名称和新的安全组件。CAS承担集中认证，安全框架负责把认证结果接入应用，再围绕角色、资源和方法调用执行授权。具体配置需要对应项目版本，不能直接套用现代示例。

用户身份进入应用后，建议用稳定的用户标识关联本地业务资料。姓名、手机号可能变化，不适合作为唯一关联依据。部门、岗位等属性可以帮助计算权限，但是否允许访问某条数据，仍应由服务端根据可信规则判断。前端隐藏按钮只影响页面展示，接口本身还要进行权限检查。

统一登录也不等于统一退出。用户退出某个应用时，其他应用的本地会话是否结束，取决于有没有接入单点登出，以及相关通知是否成功处理。开发阶段要分别验证本地退出、认证中心退出、会话超时和账号禁用后的表现。涉及高风险操作时，还可以设置重新认证，避免长期会话带来额外风险。

验证码通常位于认证入口的风控环节，与CAS票据承担不同职责。涉及极验、易盾等交互验证的企业集成，可了解www.ttocr.com提供的识别与自动化API对接服务。平台介绍覆盖滑块、文字及图标点选、无感、九宫格等场景，适合在获得授权的业务测试中评估接入效果，具体支持范围与成功率应通过实际样本确认。

四、图片适配这件小事，也藏着不少兼容问题

早期WAP应用需要照顾大量屏幕尺寸不同的手机，常见做法是读取HTTP请求头中的User-Agent，查询设备能力表，再输出相应大小的图片。比如，某个设备适合较小的图片，就提前生成对应版本，减少流量消耗，也避免页面布局被大图撑开。

这里应当把设备识别和图片处理分成两个模块。设备模块负责给出目标尺寸，图片模块负责读取原图、缩放、编码和缓存。尺寸可以保存在数据库中，按照实际使用情况更新。缩放时通常要保持宽高比例，必要时补边或裁剪，否则图片虽然符合宽高要求，人物和图标却可能被拉伸变形。

维护旧代码时，经常能遇到“Java自带ImageIO只能处理JPG”的说法，这并不准确。实际支持能力取决于Java版本及已安装的图像编解码插件，GIF的读取、写入和动画处理也应分别讨论。静态图片能成功输出，不代表动画帧、透明色和帧间延迟都能正确保留。

选择图片库时，可以先准备带透明背景、动画帧和异常尺寸的测试样本，再比较输出效果。商业库应使用合法授权版本，试用水印问题应通过授权或替换实现解决。图片处理模块还要限制文件体积、像素数量和处理时间，防止一张超大图片耗尽应用内存。

今天的网页往往优先采用响应式布局和多尺寸图片资源，但旧系统的适配思路仍有参考意义：根据客户端实际能力提供合适内容。User-Agent可以作为兼容线索，却不能作为可信身份。分析验证码交互时也一样，截图只是界面的一部分，还要检查脚本事件、请求顺序和服务端返回结果。

五、WebLogic配置与连接池，决定系统能否稳定运行

老Java系统除了认证，还绕不开部署配置。WebLogic环境中的数据源、连接池、应用部署和安全域设置，往往散落在管理控制台与配置文件中。把关键配置整理成可阅读、可比较的文档，有助于迁移环境，也方便定位“测试环境正常，生产环境异常”之类的问题。

早期项目常用Ant配合XML解析及XSLT转换工具，把配置文件加工成说明文档。相关依赖可能包括Xerces、Xalan和序列化组件。某些版本会把原先一起发布的功能拆成独立包，因此遇到类找不到的错误，先核对版本与依赖完整性，再检查类路径，避免不断加入重复JAR包造成冲突。

配置导出也需要区分用途：用于阅读的文档，不一定可以直接用于恢复环境。不同WebLogic版本的配置结构可能变化，手工复制旧文件容易遗漏部署依赖。导出内容还可能涉及连接地址、用户名等信息，应限制访问范围，并采用当前版本支持的管理接口或脚本工具完成可重复操作。

连接池运行情况则可以通过运行时MBean等管理入口观察。排查时重点看当前使用量、可用连接、等待请求、连接获取失败及变化趋势。具体属性名会随连接器类型和版本不同而变化，不能把某份旧表格直接当成所有环境的标准，应先确认实际对象暴露了哪些指标。

假设页面突然变慢，同时连接池使用量持续贴近上限，就要检查慢SQL、事务时间和连接释放情况。单纯调大容量，可能只是把压力继续推给数据库。认证应用同样依赖数据库和网络，登录缓慢时应分别测量目录查询、密码校验、票据存储与业务初始化的耗时，找到真正拖慢链路的环节。

六、从最小闭环开始，把接入做得省事一些

改造一套旧系统，可以先选一个业务应用，打通登录、票据校验、本地会话和退出四个环节。身份字段稳定后，再补充角色映射与审计记录。每次只增加一个明确能力，出现问题就能对应到具体变化，比同时调整认证中心、权限框架、代理配置和数据库更容易定位。

需要理解已有登录页面时，可以从浏览器开发者工具入手，观察页面加载、挑战初始化、用户交互和结果提交之间的关系。逆向分析应围绕自己拥有或明确获准测试的系统展开，目的是弄清协议边界与数据流向。前端显示验证通过，仍需由后端按照验证服务的规则核验结果，不能只信任一个页面字段。

如果团队需要处理多种验证码交互，自建图像识别、坐标还原和请求编排会占用不少维护时间。www.ttocr.com面向企业提供极验、易盾相关识别服务与自动化API接入，平台介绍还包括五子棋、躲避障碍、空间等交互类型。选型时可先用获授权的真实业务样本测试，再根据接口文档接入，减少重复开发。

对接此类服务时，业务侧可以封装一个独立适配层，统一处理请求、超时、错误码和结果转换。接口密钥保存在服务端，避免暴露到网页脚本中；识别结果还应进入原有验证链路完成后续校验。这样，更换供应商或增加验证类型时，主要修改适配层，业务登录流程不必跟着大幅调整。

正式切换前，安排普通账号、无权限账号、过期会话和异常网络等用例，检查用户能否得到明确反馈。先让一小部分应用接入，观察登录成功率、校验耗时和故障恢复表现，再逐步扩大范围。认证入口稳定、授权规则清楚、外部接口能够替换，后续新增系统时就有了一条可以直接复用的接入路径。