企业官网建设流程全解析

前阵子接了一个客户需求，环境里已经有泛微OA、金蝶、帆软报表、若依框架改造的一套业务系统，统一认证用的是CAS，现在要求把Oracle PLM Agile 936也纳入这套单点登录体系。拿到需求的时候，我下意识觉得“这不就是配个LDAP嘛”，真动手才发现，Agile 936这个老牌PLM系统的认证链路比想象中要绕，尤其是它同时存在Java客户端和Web客户端两个入口，认证机制完全不同，直接照着常规Web应用去配，十有八九会在某个隐蔽环节卡住。

这篇文章就把我在Agile 936上做单点登录配置的完整思路、选型对比、实操步骤和踩坑记录整理出来。不管是刚接触PLM系统的新手，还是已经摸过一阵子Agile的老手，只要你的目标是把Agile 936接到AD/LDAP、CAS、OAM这类统一认证体系里，这篇内容都值得你花十分钟看完。我不会只丢给你几个配置项，还会讲清楚为什么这么配、每条配置背后解决什么问题、不同路径之间的取舍逻辑是什么。

1. 为什么Agile 936做单点登录，比普通Web系统麻烦得多

Agile 936之所以在SSO这件事上容易让人翻车，根本原因在于它的认证架构和常规Web应用不一样。很多系统所谓的“做SSO”，本质上是把登录页面替换成统一认证页面，认证通过后回调一下就行，但Agile 936这里有两个入口、两套认证链路，只搞定其中一个不算完。

1.1 双登录入口：Java Client与Web Client各走各的认证链

Agile PLM 9.3.6的用户日常使用方式通常是两种：一种是安装版的Java Client（也就是常说的桌面客户端，界面偏传统，但功能最全）；另一种是浏览器直接访问的Web Client。这两者的体验差异很大，很多老用户更习惯用Java Client，因为它承载了产品设计、BOM管理、变更流程等重度操作。

问题就在这里：Java Client和Web Client虽然共享同一套Agile内部用户数据和权限体系，但它们各自的认证通道是不同的。Web Client走的是应用服务器层面的HTTP认证流程；Java Client则是通过AAS（Agile Application Server）的认证服务完成身份校验，认证过程走的是应用自身的通讯协议，跟浏览器里的Cookie、Session完全是两回事。

这意味着，你如果只配好了Web端的单点登录，用户打开浏览器能直接进系统，但双击Java Client又会弹出来一个登录框要密码。反之亦然。所以做SSO方案时，必须把这两条链路都考虑进去，否则上线后一定会被用户吐槽“还不是要输密码”。

1.2 认证通过不等于授权通过：外部目录只解决“你是谁”

还有一层容易忽略的机制：Agile 936内部的用户体系是独立于外部目录的。所谓外部认证，本质上是把“验证密码是否正确”这件事交给AD或LDAP去做，但Agile仍然需要在自己的用户表里找到对应的用户记录，再根据这条记录关联的权限组、角色、访问控制列表来决定用户能看哪些数据、能操作哪些功能。

打个比方：外部目录相当于小区门口的门卫，他负责确认“你是不是这个小区的业主”，确认完放你进小区；但Agile内部的权限体系相当于单元楼里的门禁，就算你进了小区，如果Agile用户表里没有你的门禁授权记录，你照样进不了任何一间屋子。

这就引出一个非常关键的配置步骤——用户映射。外部认证通过后，Agile必须知道“这个AD用户对应哪个Agile内部用户”。通常的做法是约定一个唯一标识，比如AD账号的sAMAccountName和Agile的用户名保持一致，或者通过邮件地址、员工编号等属性来关联。这个映射细节如果没处理好，就会出现登录成功但页面空空如也、或者直接报“用户不存在”的诡异现象。后面第3节我会专门讲映射规则怎么落地。

2. 动手之前先选型：三种落地路径的对比与取舍

别急着去翻配置文件。先想清楚你到底要的是“统一账号”还是“真正的单点登录”，这两个目标对应的方案差别非常大。我在实际项目里见过太多人一上来就想上SAML，结果项目周期拖了两个月还没上线。这里把三种常见路径摊开来对比一下，你再对号入座。

2.1 路径一：AD/LDAP外部认证（统一账号，但不是严格SSO）

这是Agile 936原生支持度最好、实施成本最低的方案。原理很简单：把Agile的密码校验委托给AD/LDAP服务器，用户登录时输入的账号密码由AD来验证。用户不需要再单独维护一套PLM密码，但每次打开系统仍然要输入一次用户名和密码。

这种方案在客户现场通常被称为“统一身份源”或者“账号打通”，它解决的是密码不统一、账号重复、人员离职后权限难回收的问题，但并没有实现“登录了一个系统，其他系统免登录”的体验。如果你所在的企业对SSO的定义是“必须一次登录全部免认证”，那这条路径只能算打基础，不算终点。

2.2 路径二：反向代理+CAS/自研Filter（Web端真SSO）

如果企业已经有CAS Server或者其他统一认证中心，Agile Web端可以通过前置反向代理加自定义认证过滤器的方式实现真正的一次登录到处访问。核心思路是：让认证中心的Filter拦截Agile Web应用的请求，未认证则跳转到认证中心登录，认证通过后把用户身份通过特定方式传递给Agile。

这条路径的优点是能真正实现Web端SSO，实施周期可控，不依赖Oracle商业组件；缺点是需要写一点定制代码，而且对Java Client基本无能为力。大多数把Agile接入CAS的客户，实际落地的都是Web端方案，Java Client另行处理。

2.3 路径三：OAM/SAML正式集成（正规但重）

Oracle官方主推的Agile SSO方案一般是和Oracle Access Manager（OAM）配合，走SAML 2.0或者OAM WebGate的HTTP Header身份断言。这种方案“正规”，有官方文档支持，安全模型完整，适合那些对审计、合规要求极高的大型企业。

但代价也很明显：首先OAM本身是一套重量级产品，得单独部署和维护；其次Agile和OAM的集成涉及一堆参数联调，牵一发动全身；最后如果你们企业根本没有OAM这套东西，只为了一个PLM去单独上一套OAM，成本上完全划不来。

2.4 三种路径的对比与我的取舍建议

从我个人的实施经验看，如果在客户现场只能选一个方案，我通常建议从AD/LDAP外部认证做起，先把账号体系统一了，让用户不用再记PLM专用密码；等项目验证通过、IT团队有余力了，再在Web端叠加CAS或自研Filter实现真SSO。一步到位上OAM的方案，除非企业本来就有这套设施，否则我不建议为了Agile单独引入。

3. 最稳的第一步：AD/LDAP外部认证配置实操

这一节是全文的重头戏。我把AD/LDAP外部认证从账号规划到配置验证的完整过程拆开来讲。不同小版本的Agile 936在配置项名称上可能略有差异，但核心思路是通用的，你理解了这条链路之后，换成具体版本也就是查一下对应文档的事。

3.1 配置前的账号规划：服务账号、测试账号、回滚预案

做任何认证系统改造，第一步都不是改配置，而是做账号规划。我先说三个必须提前定义好的账号角色：

• LDAP服务账号：Agile服务器用来连接AD/LDAP时使用的账号，这个账号只需要具备读取目录中用户信息的权限，不需要太高权限。建议单独建一个专用服务账号，比如svc_agile_bind，避免拿管理员账号去配，否则一旦密码轮换或者账号被禁用，整个PLM登录就瘫痪了。
• 测试账号：配置过程中肯定要反复验证登录效果，千万不能用管理员账号直接试。建议准备两个测试账号：一个AD账号和Agile内部用户名一致，另一个刻意不一致，用来验证映射规则是否生效。
• 回滚预案：改动Agile认证配置前，一定要备份原配置文件，同时确保至少有一个本地内部用户（绕过外部认证的超级管理员）可以用来登录恢复配置。这一点极其重要，后面第6节我会讲一个因为没留后路导致全员无法登录的真实案例。

3.2 核心配置项逐项说明：以现有环境为例

在Agile 9.3.6中，外部认证相关配置通常集中在AAS（Agile Application Server）安装目录的配置文件夹内。我在多个客户现场接触到的实际文件名略有出入，有的环境叫server.properties，有的环境在agile.properties里维护，还有一些配置通过AAS管理页面维护。下面给出的配置结构是业界常见的模式，键名在不同补丁版本下可能有些小变化，但参数含义是一致的：

# 是否启用外部认证，true表示密码校验交给LDAP/AD agile.external.auth.enabled=true # LDAP服务器地址和端口，389是明文LDAP，636是LDAPS（加SSL） agile.ldap.provider.url=ldap://192.168.10.20:389 # 如果使用AD域，通常用ldap://域名:389的方式，配合DNS解析 # 服务账号DN，用于Agile连接LDAP时做Bind操作 agile.ldap.security.principal=CN=svc_agile_bind,OU=ServiceAccounts,DC=corp,DC=local agile.ldap.security.credentials=此处填服务账号密码 # 用户搜索的起始DN，也就是从哪个目录节点开始找人 agile.ldap.base.dn=DC=corp,DC=local # 用户搜索过滤器，{0}会被替换成用户登录时输入的账号 # 对AD来说，最常用的是sAMAccountName agile.ldap.user.search.filter=(&(objectClass=user)(sAMAccountName={0}))

逐个解释一下这些参数背后的逻辑：

agile.external.auth.enabled是整个配置的总开关。这个开关打开之后，Agile启动时会初始化LDAP连接池，并改变登录流程：用户提交账号密码后，Agile不再用内部密码去校验，而是去LDAP上查这个人并验证密码。

agile.ldap.security.principal和agile.ldap.security.credentials是Agile连接LDAP的凭据。为什么需要单独的Bind账号？因为Agile要根据用户输入的账号去目录里搜索用户条目，而大部分AD默认不允许匿名搜索，所以必须先用一个有查询权限的服务账号“绑定”到LDAP，然后才能执行搜索操作。

agile.ldap.user.search.filter是整套配置的灵魂。它决定了“用户输入一个账号名之后，Agile去LDAP里怎么定位到这个人”。{0}是占位符，运行时会替换成用户输入的内容。这里有个常见的误区：很多人会把过滤器写死成(sAMAccountName={0})，结果用户输入ZHANGSAN时能匹配到，但输入zhangsan@corp.local这种UPN格式就失败了。就是因为过滤器只认sAMAccountName，不认userPrincipalName。所以如果你希望用户可以用邮箱格式登录，过滤器就要改成(|(sAMAccountName={0})(userPrincipalName={0}))。

3.3 用户映射规则：AD账号和Agile用户怎么对上号

配置完LDAP连接，只是让Agile能“认识”AD里的用户，但Agile内部还是要在自己的用户表里找到对应记录，才能关联权限。这一步是很多项目配置完却登录不了的头号原因。

常见的映射规则有三种：

1. 账号名一致：AD的sAMAccountName和Agile内部用户名完全一致。这是最省事的做法，实施前需要批量比对两边的账号列表，把不一致的账号在Agile里改名或者新建。
2. 邮件地址关联：AD的mail属性和Agile用户信息里的邮件地址一致。适合企业里AD账号和Agile账号命名规范不一致的情况，但前提是两边邮件地址都维护得规范。
3. 员工编号关联：AD自定义属性（比如employeeNumber）和Agile用户自定义属性一致。这种映射最准确，但需要做属性映射配置，实施工作量最大，适用于对人员身份准确性要求极高的企业。

我经手的项目里，80%的客户最终都选了第一种，账号名一致。不是因为别的，就是因为它最好维护、最好排查。你得记住一个关键点：映射规则一旦建立，后续AD里新入职人员的账号命名规范就必须与Agile保持一致，这个约束要提前跟客户的人力系统和IT运维团队对齐，否则上线三个月后就会冒出各种“AD有这个人但Agile登录不了”的工单。

3.4 验证流程：从bind测试到真实登录

配置完成后，不要直接扔给用户试，按下面这个顺序逐步验证：

第一步：验证LDAP连接字符串和Bind账号

在Agile服务器上用命令行工具（比如ldapsearch或PowerShell的ADSI）手动执行一次LDAP搜索，确认服务账号能连接、能执行搜索：

ldapsearch -x -H ldap://192.168.10.20:389 \ -D "CN=svc_agile_bind,OU=ServiceAccounts,DC=corp,DC=local" \ -w '密码' \ -b "DC=corp,DC=local" \ "(&(objectClass=user)(sAMAccountName=testuser01))"

能返回用户条目，说明连接字符串、Base DN、过滤器这三个要素都正确。如果报错，绝大多数情况是Base DN写错，或者服务账号没权限读取对应OU。

第二步：在Agile测试环境修改配置并重启AAS

把配置写进正式环境的配置文件之前，先在一台测试服务器上完整走一遍。重启AAS之后，查看启动日志，确认没有LDAP初始化异常。

第三步：用测试账号登录Java Client

用AD账号登录Java Client，登录成功且能看到测试账号对应的权限数据，说明外部认证链路全通。再故意输错一次密码，确认密码校验确实由AD决定（错误密码无法登录）。

第四步：用Web Client重复同样测试

Web Client和Java Client在执行外部认证时的细节有差异，必须两端都验证一遍。

到这里，AD/LDAP统一账号方案就算落地了。用户在PLM里输入的密码变成了AD密码，账号生命周期管理也归到了AD这边。

4. Web端真SSO落地：应用服务器拦截与用户身份传递

如果你们的统一认证中心是CAS，或者你想完全去掉Agile登录页面，让用户从OA门户点一下就直接进入PLM Web端，那就需要走这一节的内容。先说结论：这条路径的本质，是在Agile Web应用前面加一道“信任代理”，由这道代理负责和统一认证中心打交道，认证通过后，把用户身份“交底”给Agile，Agile选择信任交底结果，直接建立会话。

4.1 认证前置的两种形态：WebGate与反向代理

在Agile 936前面放置认证前置组件，常见两种形态：

一种是OAM WebGate，它挂在Web服务器层，拦截所有到Agile的请求，未认证用户被重定向到OAM登录页，认证通过后OAM把用户身份写入请求头（比如OAM_REMOTE_USER），Agile通过这个Header识别用户。这种形态正规、安全，但依赖OAM产品。

另一种是反向代理加自定义认证Filter，这是和CAS集成时最常见的姿势。架构上大致是：

浏览器 → CAS统一登录页 → 反向代理/认证Filter → Agile Web应用

用户访问PLM的Web地址时，请求先被一个认证Filter拦截。如果当前会话没有认证标识，就重定向到CAS Server的登录页；用户在CAS登录成功后，CAS回调并携带一个用户标识（CAS的eduPersonPrincipalName之类的属性），Filter拿到这个标识后，再决定如何让Agile“认”这个用户。

4.2 Header里的用户身份如何变成Agile会话

这里才是技术上的关键点。CAS认证通过后，你拿到了用户名，但Agile不会平白无故相信你。必须让Agile认为“当前请求来自一个已经通过外部认证的用户”。最常见的实现方式有两种：

方式A：通过请求头传递用户名，由Agile的外部认证机制识别

定制Filter在把请求转发给Agile应用之前，往请求里写入一个约定的请求头，比如X-Remote-User。Agile的认证模块配置为信任该请求头，读取到值后直接尝试用这个用户名建立会话，不再弹登录框。这种方式配置起来直接，但安全性较依赖网络边界，必须要保证外部用户无法直接绕过反向代理访问Agile。

方式B：调用Agile的外部认证API，主动完成会话建立

Filter通过Agile提供的认证接口，把用户名和一个预设的“信任令牌”发送给Agile，Agile验证令牌合法后，为用户建立一个内部会话。这种方式更接近官方集成语义，安全性更高，但需要查阅当前版本的接口文档，开发工作量稍大。

4.3 一个可用的Filter写法与部署注意

这里给出一个简化版的Filter示例，思路是：接收到请求后，从请求头X-Remote-User里取用户名，如果存在则将用户名写入request属性，并跳过后续拦截，实际项目中你要视具体Agile版本调整会话建立方式：

public class AgileSsoFilter implements Filter { private String trustedHeader = "X-Remote-User"; @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest httpRequest = (HttpServletRequest) request; String userName = httpRequest.getHeader(trustedHeader); if (userName != null && !userName.trim().isEmpty()) { // 将信任的用户名设置到会话上下文中 httpRequest.getSession(true).setAttribute("agile.sso.user", userName.trim()); // 此处省略调用Agile外部认证接口建立PLM会话的代码 } else { // 未携带可信头，重定向到统一认证中心 // 此处省略重定向到CAS登录页的代码逻辑 } chain.doFilter(request, response); } @Override public void init(FilterConfig filterConfig) throws ServletException { // 初始化时可读取配置参数，比如trustedHeader从web.xml中注入 } @Override public void destroy() { } }

这段代码只是引导思路，生产环境必须补充：Header来源校验（只允许内部代理IP）、会话超时处理、用户不存在时给清晰报错等。部署上，Filter要打包成WAR包里的Filter或放到Agile Web应用前端的代理层。

4.4 这套方案的安全边界：防止Header伪造

自研Filter方案最容易被攻击的点就是请求头伪造。如果攻击者直接构造一个带了X-Remote-User: admin的HTTP请求，而Agile又完全信任这个Header，那等于门户大开。

所以必须强调两条底线：

• 反向代理和Agile应用之间必须限定在受信内网，不能让用户直接绕过代理访问Agile；
• Filter里必须校验来源IP白名单，或者对Header内容做签名校验。更可靠的方式是代理在转发前把认证信息加密签名放到Header里，Filter验签后使用，而不是直接信任明文用户名。

我见过不少自己玩脱的案例，基本都是因为图省事直接信任了Header，最后安全审计一查一个准。这块省不得。

5. Java Client这个老大难：三种被验证过的处理方式

Web端SSO搞定之后，Java Client怎么办，这是每个Agile集成项目绕不开的痛。有人为了彻底实现“双端SSO”，耗费大量精力去做Java系统的深度集成，最后得不偿失。这里给你三个被验证过、值得考虑的处理方式，按推荐程度从高到低排。

5.1 为什么Java Client不适合浏览器式SSO

Java Client不是一个浏览器页面，它是一套独立的Swing桌面应用。它的登录流程里没有“重定向到一个统一登录页再跳回来”这种Web交互模式。浏览器里的SSO依赖Cookie、跨域跳转、Session机制，这些在Swing客户端里都不存在。你可以把它理解成：Agile的桌面客户端是一个独立的“设备”，它直接和AAS服务端通信，要求你提供账号密码（或者通过特定启动参数携带凭据），服务端验证后返回会话。这个过程没有浏览器参与，自然就没有统一的“登录入口”可以拦截。

5.2 方式一：客户端启动脚本读取域账号自动填充

大多数企业里，用户登录Windows电脑本身就是用AD账号完成的。既然用户在操作系统层面已经验证过身份了，那Java Client启动时完全可以让脚本去读取当前Windows登录账号，然后自动填充到Agile的登录界面上，用户只需要点一下登录按钮。

具体做法是：在客户端启动脚本（Windows批处理或JNLP配置）里调用whoami命令，截取当前域账号，拼接到Agile客户端的启动参数里。部分Agile客户端的登录窗口支持从启动参数预填用户名，这样用户的体验就是“打开客户端，点登录，进系统”。密码还是AD密码，但用户省去了敲账号的步骤。

这个方案非常轻量，不涉及任何开发改造，实施成本几乎为零，而且能明显降低用户抱怨。缺点是没有真正免密，但配合Windows系统“记住凭据”的功能，用户实际上大部分时间不需要重新输入密码。

5.3 方式二：远程应用发布收口客户端

如果企业对安全要求高，不想在每台员工电脑上安装Java Client，也不想面对客户端版本升级的运维地狱，可以考虑用Citrix、远程桌面服务或者应用虚拟化平台把Java Client统一发布。

用户通过浏览器访问远程应用平台，登录平台时已完成一次身份认证，平台内再打开Agile Java Client时，借助会话保持机制，用户不需要再次输入PLM账号密码。这种方案从用户体验上几乎等同于“SSO”，而且客户端软件集中在服务器端维护，IT运维省了一大截功夫。缺点是远程应用平台本身有授权成本，网络带宽要求也更苛刻，适合总部集中管控的部署模式。

5.4 方式三：官方AutoLogin或外部认证配合

Agile的部分版本提供了自动登录（AutoLogin）机制，在受信任的内网环境中，客户端启动时可以通过启动参数携带用户名，由服务器在预先配置的白名单内直接放行。这种方式听起来最完美，但实际限制比较多：通常要求客户端和服务器处于同一内网网段，对IP、主机名有严格约束，而且密钥管理麻烦。

如果你的环境允许，可以在启用AD外部认证的基础上，尝试结合AutoLogin机制进一步减少登录交互。我的建议是：先确认你们当前补丁版本的官方文档是否支持，不要轻信社区里的“传说级”配置。

5.5 交互层面对用户的引导

技术方案定了，还得做好用户预期管理。Java Client的SSO体验大概率做不到和Web端一样顺滑，上线前的用户通知里最好明确说明：“PLM桌面端登录仍需输入域账号密码，但账号密码与Windows一致，支持记忆功能；浏览器端已实现免登录进入。”把话说清楚，比让用户自己去发现“怎么还要输入密码”再抱怨，体验要好得多。

6. 实施现场最容易翻车的环节与排查复盘

最后这部分，我挑几个在真实项目里反复出现的翻车场景，每个都对应一条排查经验。你实施的时候如果遇到类似问题，直接照着这个思路查，能省不少时间。

6.1 配置变更前先备份：防止全员无法登录

有一条铁律：改认证配置前，先备份原配置文件。别觉得这是废话，我见过太多人改完配置重启服务，发现外部认证没生效，想回退却发现原文件已经被覆盖了。Agile的认证配置改动影响面是系统级的——一处配置失误，所有用户都无法登录，包括管理员。

正确的操作顺序是：

1. 复制原配置文件到带时间戳的备份目录；
2. 确认有一个绕过外部认证的本地内部管理员账号，且密码有效；
3. 修改配置；
4. 重启AAS并观察启动日志；
5. 在测试环境验证通过后再应用到生产环境。

6.2 LDAP连不上：URL、端口、证书三件套

配置完外部认证后，只要LDAP连接有问题，Agile启动时或者用户登录时就会报错。排查顺序固定：先测URL通不通、再测Bind账号能不能用、最后查证书。

AD的LDAP默认端口是389（明文）和636（LDAPS）。如果公司安全策略要求走加密，必须用636，还要把AD服务器的根证书导入到Agile所在服务器的Java信任库（cacerts）里。这个步骤特别容易被遗漏，症状是：证书没导入时，Agile启动日志里报SSL握手失败，但你在AD服务器本地用同样的服务账号测试却能连接成功。这就是典型的客户端信任库问题，不要怀疑AD配置，去补证书就行。

6.3 登录成功但看不到任何工程数据：映射问题的典型表现

外部认证配好之后，用户登录不报错，但系统里看不到任何项目数据，或者进去是一个“全新”的空账号。这个症状基本可以锁定为用户映射失败或权限未关联。

排查时先确认Agile用户表里有没有这个账号，再确认这个账号关联的权限组和角色是否正常，最后查外部认证配置里的用户搜索过滤器是否选错了属性。比如AD里同时存在sAMAccountName=zhangsan和mail=zhangsan@corp.local，过滤器如果用mail匹配，但Agile内部用户名存的是zhangsan，两边就对不上。

6.4 日志定位三板斧

出问题第一反应别去猜，去看日志。Agile相关日志主要集中在两个地方：

• AAS应用服务器日志：通常能看到认证异常、LDAP连接失败、Session创建失败等关键信息；
• Agile应用自身的日志：能看到用户映射、权限初始化等细节。

遇到登录类问题，按这个顺序查日志：AAS启动日志里有没有LDAP初始化异常；用户登录时认证链路有没有报错；认证通过后用户映射环节有没有警告。大多数问题在三板斧之内就能定位。

6.5 一个真实排错案例：管理员被外部认证锁在门外之后

有一次我在客户现场配置外部认证，客户IT管理员激动地把配置改完就重启了生产环境的AAS，结果发现AD服务账号密码已经过期，外部认证初始化失败，所有用AD账号登录的用户全部被挡在门外。更要命的是，原有的内部管理员账号刚好被前一天的安全策略改了密码，而那个密码只有离职的同事知道。

最后花了整整半天时间，通过停机维护模式、手工调整数据库用户状态才恢复系统。这件事之后，我到任何客户现场做认证类改造，第一件事永远是确认“绕过外部认证的本地管理员账号是否可用”，并且把这个检查项写进变更方案的第一条。希望你看到这个案例之后，也能记住这条教训。

最后再分享一点个人体会

Agile 936的单点登录配置，难点从来不在某个具体的配置项上，而在于想清楚边界：你到底要统一账号，还是要真SSO；你服务的主要入口是Web端还是Java Client；你能接受多少定制开发量。把这几个问题想清楚了，再回头查配置文档，你会发现所有步骤都是顺理成章的。

我个人经手多个项目后的最终建议是：先上AD/LDAP外部认证，把账号体系统一这件事做实，这永远是性价比最高的第一步；Web端根据企业已有认证中心叠加CAS或自研Filter；Java Client不要硬追求浏览器式的SSO体验，用启动脚本自动填充加远程应用发布的组合拳，基本就能让用户满意。配置类的变更，永远先在测试环境完整演练一遍再上生产，这句话值得再强调一次。