企业身份与账号集成可以按“盘点范围—分步实施—角色分工—生命周期流转—上线检查”的顺序推进：先确定唯一账号主数据源，再选择协议与同步方向，按“主数据源→统一认证→应用接入→账号生命周期同步”分批实施，每批用登录成功率、开通与停用时效、异常账号数验证后再扩展。本文聚焦身份认证与账号，访问授权策略和文档权限不在讨论范围。
要点总览（TL;DR）
- 先盘点身份源与待接入应用，确定唯一账号主数据源，再决定协议与同步方向。
- 按“主数据源→统一认证→应用接入→账号生命周期同步”的顺序分批实施，先选1–2个应用试点。
- 入职、转岗、离职三类事件映射为账号动作，自动同步用SCIM等标准协议，不支持的应用列入人工清单。
- 上线前逐项确认单点登录、开通与停用时效、重复与孤儿账号清理、回退方案和监控指标。
- 集成完成后账号规则、应用清单和回收要求需随组织变化持续维护。
先定范围：身份源、应用清单与账号口径
集成的第一步是盘点，产出两张表和一个结论：身份源清单、待接入应用清单，以及“以哪个目录作为唯一账号主数据源”的明确决定。这一步做扎实，后面的同步方向、协议选择和分批顺序才有依据。
盘点身份源
把企业当前产生和存放账号的系统逐一列出，常见的有四类：企业目录（如AD/LDAP或云目录）、HR系统、邮箱域、已有的身份提供方（IdP）。每个身份源记录三项信息：账号数量、由谁维护、更新频率。重点识别哪些系统在“创建账号”，哪些只是在“使用账号”，前者才是主数据源的候选。
列出待接入应用
应用清单建议包含以下字段，便于后续排期：
| 字段 | 填写内容 | 用途 |
|---|---|---|
| 应用名称 | 系统全称与负责人 | 确定对接联系人 |
| 用户规模 | 活跃账号数 | 评估试点风险与影响面 |
| 协议支持 | SAML 2.0、OIDC/OAuth 2.0、SCIM或仅支持自有账号体系 | 决定接入方式 |
| 账号来源 | 本地自建、目录同步或手工维护 | 判断迁移工作量 |
| 优先级 | 首批试点、第二批、后续 | 安排分批顺序 |
确定账号主数据源与命名规则
主数据源只选一个。人员数据以HR系统为源头、账号以企业目录为载体的组合较常见，此时应明确：HR系统负责“人”的入职、转岗、离职状态，企业目录负责“账号”的生成与停用，两者之间是单向同步关系。账号命名规则同步定下来，例如以工号或邮箱前缀作为唯一标识，并约定重名时的处理方式。规则一旦确定，所有应用按同一口径对接，避免各系统各自生成账号。
核心操作步骤：从目录对接走到应用上线
以下五步按依赖关系排列，每步给出输入、动作、输出和完成标志。企业可按自身规模压缩或拆分，但顺序不建议颠倒。
步骤一：搭建或确认统一身份提供方（IdP）
输入：组织架构数据、人员名单、账号命名规则。动作：已有IdP的，核对其组织树与人员数据是否完整；没有的，完成IdP部署并将组织与账号导入。输出：可登录的IdP，组织架构与人员账号齐备。完成标志：随机抽取若干员工，能在IdP中查到其账号与所属组织，且组织层级与实际一致。
步骤二：打通主数据源到IdP的同步
输入：主数据源字段说明、IdP账号字段定义、同步频率要求。动作：建立字段映射（如工号、姓名、部门、状态），配置定时同步或事件触发同步。同步方向定为单向写入，即主数据源→IdP；应用侧回写需单独评估，避免形成环路。输出：可运行的同步任务与字段映射文档。完成标志：在主数据源新增或修改一条人员记录，约定时间内IdP中对应账号正确生成或更新；连续观察若干同步周期无重复账号产生。
步骤三：接入首批试点应用，完成单点登录联调
输入：试点应用清单（建议1–2个，用户规模适中、协议支持明确）、应用侧对接参数。动作：按应用支持的协议配置信任关系：传统企业应用多用SAML 2.0，现代Web与移动应用多用OIDC/OAuth 2.0。由应用负责人提供对接参数，身份管理员在IdP侧完成配置，双方联调登录、登出与异常提示。输出：试点应用的单点登录配置与联调记录。完成标志：试点用户从IdP发起登录可直达应用，无需二次输入应用密码；登录失败时有明确错误提示且可在日志中查到。
步骤四：配置账号生命周期
输入：入职、转岗、离职的业务规则与时效要求。动作：把三类事件映射为账号动作：入职触发账号创建与应用开通，转岗触发组织归属与应用范围调整，离职触发账号停用与回收。需要自动同步的应用使用SCIM等标准协议下发账号变更，不支持自动化的应用列入人工处理清单并指定责任人。输出：生命周期规则表，含每类事件的触发条件、执行动作、时效要求。完成标志：用测试账号完整走一遍入职、转岗、离职流程，各环节动作在约定时效内完成。
步骤五：分批扩展并处理例外账号
输入：应用清单中的第二批、第三批应用，例外账号清单。动作：按优先级逐批接入，每批完成后执行与试点相同的验证。例外账号包括：无法对接协议的应用、外部协作人员账号、历史遗留的本地账号，逐条登记处理方式与责任人。输出：全部应用接入状态表、例外账号处理台账。完成标志：清单内应用全部完成接入或登记例外；例外账号均有明确处理结论。
角色分工与各环节交付物
身份与账号集成横跨IT、应用、HR和安全多个角色，把责任和交接物写清楚，能减少“配置完了没人验证”“人员数据不准导致账号错开”这类返工。
| 角色 | 主要任务 | 交付物 | 交接节点 |
|---|---|---|---|
| IT/身份管理员 | IdP配置、目录同步、账号命名规则落地 | 同步任务与字段映射文档、IdP配置记录 | 向应用负责人交付对接参数 |
| 应用负责人 | 提供协议与对接参数，完成应用侧配置 | 应用接入配置说明、联调记录 | 联调通过后移交运维 |
| HR或组织管理员 | 保证人员异动数据准确、及时录入 | 入职、转岗、离职数据的录入时效记录 | 异动数据进入主数据源即触发同步 |
| 安全与合规角色 | 确认账号回收要求与审计范围 | 账号回收时效要求、审计日志留存要求 | 上线前确认检查项，上线后定期复核 |
交接节点需要具体到可核对的物：应用负责人拿到对接参数才算接手配置，联调记录签字才算完成移交，安全角色确认的回收时效写入生命周期规则表才算生效。研发团队日常在项目与工作项中协作时，成员账号的开通与停用同样依赖上述流程；ONES的成员管理与工作项分配可以承接这类人员变动后的协作安排，账号本身仍由统一身份体系管理。
示例：一次入职到离职的账号流转
以下为演示情景，用于说明集成后的流转过程，具体时效按企业约定填写。
新员工入职
HR在HR系统录入新员工信息并标记入职日期。主数据源同步任务在约定时间内将人员记录写入IdP，IdP按命名规则生成账号。账号创建事件触发应用开通：支持SCIM的应用自动获得账号并加入对应组织组，不支持的应用由责任人按清单手工开通。完成标志是新员工首次登录即可访问其岗位所需应用，无需逐个申请账号。
转岗
HR更新员工的部门与岗位信息，同步任务将变更写入IdP，组织归属随之调整。应用侧根据组织组变化调整账号范围：原岗位应用访问范围收窄，新岗位应用范围放开。这里调整的是账号归属与应用开通范围，具体的角色权限设计属于访问授权策略，另行处理。
离职
HR将员工状态改为离职，同步任务在约定时效内将IdP账号停用，停用事件触发各应用账号回收。安全角色事先确认的回收时效写入规则表，例如“离职生效后当日停用统一账号，约定天数内完成全部应用回收”。完成标志是抽查离职人员账号在各应用中均不可登录。
异常情况处理
账号重复通常源于同一人存在多个标识（如工号与邮箱前缀不一致），处理方式是回到命名规则统一标识，合并或停用多余账号。应用侧残留账号多出现在未接入自动回收的应用中，处理方式是定期比对IdP账号清单与应用账号清单，差异项登记到例外账号台账并指定清理责任人。
完成检查：上线前要逐项确认的事
上线判断以可核验的结果为准，建议按下表逐项确认，全部通过再宣布上线。
| 检查项 | 通过标准 | 确认人 |
|---|---|---|
| 试点应用单点登录 | 试点用户从IdP登录可直达应用，登录失败有提示且日志可查 | IT/身份管理员、应用负责人 |
| 账号开通时效 | 测试入职流程中账号在约定时效内生成并完成应用开通 | IT/身份管理员 |
| 账号停用时效 | 测试离职流程中统一账号与应用账号在约定时效内停用 | IT/身份管理员、安全角色 |
| 重复账号与孤儿账号 | 比对清单完成，重复账号已合并或停用，孤儿账号已登记处理结论 | IT/身份管理员 |
| 回退方案 | IdP故障时的应急登录路径已确定并演练过，责任人明确 | IT/身份管理员 |
| 上线后监控 | 登录成功率、开通与停用时效、异常账号数有采集方式，指标责任人和复核周期已确定 | IT负责人、安全角色 |
监控指标的具体阈值由企业按自身规模约定，例如登录成功率的目标值、离职停用的最长时限。上线后按复核周期检查指标，异常项回到对应步骤排查：登录失败集中出现查协议配置，开通延迟查同步任务，残留账号查例外台账。集成不是一次性项目，账号规则、应用清单和回收要求随组织变化持续维护，才能保持账号与人员状态一致。
常见问题
企业已有AD或云目录，还需要单独建一个IdP吗？
不一定需要新建。已有企业目录或云目录时，先核对其组织树与人员账号是否完整，能承担统一认证职责的可以直接复用，把工作重点放在目录到应用的协议对接上。需要新建IdP的常见情形是：现有目录只覆盖部分人员、无法支持SAML 2.0或OIDC/OAuth 2.0等标准协议，或者多个目录并存且没有统一入口。无论复用还是新建，账号主数据源仍应只保留一个，避免多源写入造成账号冲突。
HR系统和企业目录，哪个更适合作为账号主数据源？
取决于企业以“人”还是以“账号”为管理起点。常见做法是HR系统负责人员的入职、转岗、离职状态，企业目录负责账号的生成与停用，两者之间保持单向同步。这样人员异动有明确业务源头，账号规则集中在一处维护。如果企业没有可用的HR系统，也可以由企业目录承担主数据源，但需要指定专人维护人员状态，并约定录入时效，否则账号开通与回收会滞后。
部分应用不支持SAML或SCIM，怎么处理？
这类应用列入例外账号清单，逐条登记处理方式与责任人。可选做法包括：由责任人按清单手工开通和回收账号，并纳入定期比对；在应用侧保留本地账号，但要求账号命名与统一规则一致，便于核对；评估应用是否有可用的替代接入方式。例外清单需要在上线检查时确认每条都有处理结论，并在上线后按复核周期检查残留账号，避免离职人员账号长期留在应用侧。
同步方向为什么建议单向，应用侧回写有什么风险？
单向写入指主数据源→IdP→应用，账号变更只从上游流向下游。应用侧回写如果未加控制，容易出现环路：应用修改了账号字段，同步任务又把它写回IdP，与主数据源的数据冲突，产生重复账号或状态反复。确有回写需求时，应单独评估回写字段范围、冲突处理规则和触发频率，并明确以哪一侧数据为准。多数情况下，把账号状态维护集中在主数据源，应用侧只读使用，实施和排查都更简单。
上线后发现登录失败集中出现，应该从哪里排查？
先区分失败发生在哪一段：从IdP发起登录就失败，查IdP侧账号状态与认证配置；能到应用登录页但被拒绝，查应用侧的协议配置、证书与信任关系；部分用户失败而其他人正常，查这些用户的账号归属、命名规则与组织组是否一致。排查时对照联调记录和同步日志，确认最近是否有字段映射或组织架构调整。把失败原因归类记录，能帮助判断是配置问题还是数据问题，也便于后续批次接入时提前规避。
