企业身份与账号集成要解决的是“人从哪里来、怎么登录、账号何时开、何时停”这四个问题。落地时先确定唯一权威身份源，再选择SAML 2.0、OIDC、SCIM等协议组合，明确账号创建、变更、离职停用的触发方，最后用试点账号验证登录、属性传递与异常回退，再分批切换。本篇聚焦身份认证与账号生命周期，访问授权策略和知识文档权限只在边界处说明。
要点总览（TL;DR）
- 企业身份与账号集成先拆成两块：身份认证负责“能不能进来”，账号生命周期负责“账号何时存在、何时失效”，授权策略与文档权限另立主题。
- 落地按五步推进：确认唯一权威身份源与命名规则、选择SAML 2.0/OIDC/SCIM等协议组合并核对平台支持、设计属性与角色映射、用覆盖入职变更离职的试点账号验证、分批切换并准备可演练的回退方案。
- 角色分工的关键在三个交接点：目录管理员交付字段清单与测试账号、平台管理员提交映射表评审、切换前回退方案经安全与合规确认。
- 离职停用建议以单一状态字段作为触发条件，并在验收时按时延标准和残留账号抽查结果判断是否通过。
- 上线验收逐项留存证据，覆盖登录可用性、映射正确性、停用时延、异常表现与回退演练，由负责人书面确认。
先定集成范围：认证、账号生命周期与授权边界
身份与账号集成容易在启动阶段失控，常见原因是把“登录打通”和“权限治理”混成一个项目。建议在动手配置前，先把工作拆成两块可独立验收的内容：身份认证负责“这个人能不能进来”，账号生命周期负责“这个人的账号什么时候存在、什么时候失效”。两者共用同一套身份源和属性，但验收标准不同，责任人也可能不同。
身份认证的范围包括：单点登录链路的建立、登录时身份提供方与平台之间的信任配置、多因素认证由哪一侧承担、登录失败时的提示与日志。账号生命周期的范围包括：入职时账号由谁创建、依据哪些属性生成、岗位或部门变更时哪些字段需要同步、离职时停用由哪个系统触发、停用后会话和令牌如何处理。把这两块分开列，可以避免出现“登录通了但离职账号还活着”这类只验收了一半的情况。
访问授权策略、角色能看哪些项目、知识文档的可见范围与共享规则，属于权限治理主题，本篇不展开。这里只做边界说明：身份集成负责把“人”和“账号”准确地带到平台上，账号进入平台后拥有什么数据权限，由授权策略另行设计。这样划分的好处是，身份集成可以先上线并稳定运行，授权策略可以随后迭代，两者不互相阻塞。
范围界定建议用一张表固化下来，由项目负责人在启动会上确认，后续需求变更以此表为基准。
| 类别 | 纳入项 | 排除项 | 责任团队 |
|---|---|---|---|
| 身份认证 | 单点登录链路、信任配置、多因素认证归属、登录日志 | 密码强度策略的日常运营 | IT/身份目录团队主责，平台管理员配合 |
| 账号生命周期 | 入职开通、变更同步、离职停用、停用时延与残留检查 | 账号权限内容的审批流程 | IT/HR系统团队触发，平台管理员承接 |
| 属性与角色映射 | 目录字段到平台账号字段、目录组到平台角色的映射规则 | 角色对应的数据可见范围设计 | 平台管理员主责，业务代表确认 |
| 授权与文档权限 | 仅做边界说明 | 访问授权策略、知识文档权限与共享管理 | 另立主题，不在本项目范围 |
这张表的作用是让每个参与方知道自己交付什么、不交付什么。范围一旦确认，后续讨论“某个权限要不要一起做”时就有依据，不必每次重新争论。
核心答案与操作步骤：五步完成集成落地
集成的主流程可以按五步推进。每一步都应有明确的输入、动作、输出和完成标志，完成标志是进入下一步的前提，避免带着未验证的假设往下走。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：确认权威身份源与命名规则 | 现有目录清单（如HR系统、AD/LDAP、其他IdP）、人员规模与组织架构 | 确定唯一权威源，明确其他来源只做补充；制定账号命名规则与唯一标识字段 | 权威源说明、账号命名规则文档 | 所有相关方认可同一身份源，唯一标识在目录中无重复 |
| 第二步：选择协议组合并核对平台支持 | 权威源支持的协议、目标平台支持的协议、安全要求 | 确定认证协议（SAML 2.0或OIDC）与账号同步方式（SCIM或定时同步），逐项核对平台实际支持情况 | 协议选型说明与平台支持核对记录 | 每个协议都有明确的承担方与配置位置，无“待确认”项 |
| 第三步：设计属性映射与角色映射 | 目录字段清单、平台账号字段与角色清单 | 建立字段映射表与角色映射规则，标注必填、可选与默认值 | 属性映射表、角色映射规则 | 映射表覆盖全部必填字段，角色规则经业务代表确认 |
| 第四步：试点账号验证 | 映射表、试点账号名单（覆盖入职、变更、离职） | 用试点账号走通登录、属性传递、岗位变更同步、离职停用 | 试点验证记录与问题清单 | 三类情景全部通过，问题清单关闭或有明确处理计划 |
| 第五步：分批切换与回退方案 | 试点结论、用户分批名单、回退操作步骤 | 按部门或批次切换，保留旧登录方式作为过渡；准备回退开关与责任人 | 切换计划、回退方案、切换记录 | 首批切换稳定运行约定观察期，回退步骤经演练确认可执行 |
第一步的关键是“唯一”。如果HR系统和AD都能改人员信息，就必须明确以谁为准、另一方如何同步，否则后续属性冲突会反复出现。账号命名规则要提前定，尤其是重名、离职再入职、外包人员这几类情况，规则里要写清楚唯一标识用什么字段。
第二步的协议选择取决于两端能力。SAML 2.0适合以浏览器单点登录为主的场景，OIDC在移动端和API场景更常见，SCIM用于账号的自动开通与停用同步。实际项目中常见组合是“SAML 2.0或OIDC负责登录，SCIM或定时同步负责账号生命周期”。这里需要提醒：协议支持情况必须以目标平台的实际配置项为准，本篇不给出具体产品的兼容版本结论，选型时逐项核对即可。
第三步的映射设计要区分“认证时传递的属性”和“同步时写入的字段”。前者影响登录时的身份识别，后者影响账号资料与角色。角色映射建议从目录组出发，用组到角色的对应关系，避免逐人配置。映射表里每个字段标注来源、是否必填、默认值和处理异常的方式，这张表是后续试点和验收的依据。
第四步的试点账号要覆盖三类人：新入职、岗位变更、离职。每类至少准备两个账号，其中一个用于验证异常情况，比如属性缺失时账号是否按预期处理。试点阶段发现的问题应记录在问题清单里，逐条关闭后再进入切换。
第五步的分批切换建议按部门或按办公地点分批，每批保留观察期。回退方案要具体到操作步骤和责任人，例如“关闭单点登录强制开关，恢复账号密码登录”，并提前演练一次。回退方案的价值在于切换当天出现问题时，团队知道按什么顺序操作，而不是临时讨论。
角色及交付物：谁提供目录、谁配置平台、谁验收
集成项目出问题，多数不是技术难题，而是某个环节没人负责。把角色和交付物列清楚，并在关键节点设置交接与评审，可以显著减少返工。
| 角色 | 主要职责 | 关键交付物 | 交接与评审节点 |
|---|---|---|---|
| 身份目录管理员 | 维护权威身份源，提供目录字段与组织架构，执行账号开通与停用的源头操作 | 目录字段清单、组织架构导出、测试账号、停用操作记录 | 向平台管理员交付字段清单与测试账号；离职停用链路联调时到场 |
| 研发平台管理员 | 配置平台侧认证与账号同步，维护属性映射与角色映射，执行切换与回退 | 应用配置记录、属性映射表、角色映射规则、切换与回退方案 | 映射表提交业务代表评审；切换前提交回退方案评审 |
| 安全与合规 | 确认认证方式与多因素要求，审核账号停用时延与日志留存 | 安全要求说明、停用时延标准、日志与证据留存要求 | 方案评审阶段确认安全要求；验收阶段核对证据 |
| 业务团队代表 | 确认角色划分是否符合实际工作分工，参与试点验证 | 角色确认意见、试点反馈 | 角色映射评审；试点结果确认 |
交接点的设计比职责描述更重要。典型交接有三处：目录管理员把字段清单和测试账号交给平台管理员，这是映射设计的起点；平台管理员把映射表提交业务代表评审，这是角色规则定稿的节点；切换前把回退方案提交安全与合规评审，这是上线前的最后一道确认。每个交接点都应有书面记录，形式可以是文档评审意见或工单记录。
在研发平台侧承接账号与成员管理时，ONES提供成员管理与单点登录相关的管理能力，可作为账号进入平台后的承接对象：目录侧完成认证与同步配置后，平台侧按映射规则维护成员与角色。具体支持的协议与配置方式，建议以ONES官方文档和实际环境核对为准，再写入实施方案。
示例：一次从目录到研发平台的账号开通与离职停用
以下为演示情景，用于说明字段映射与状态流转的做法，字段名称和规则为示例设计，不代表任何产品的实际配置界面。
假设企业以HR系统为权威身份源，通过目录服务向研发平台同步账号，登录采用单点登录。目录中每位员工有以下关键属性：员工编号（唯一）、姓名、部门、岗位、直属上级、在职状态、企业邮箱。平台侧账号需要：登录名、显示名、部门、角色、账号状态。
| 情景 | 目录侧变化 | 映射动作 | 平台侧结果 | 验证方式 |
|---|---|---|---|---|
| 新员工入职 | 新增员工记录，在职状态为“在职”，部门与岗位已填写 | 员工编号映射为登录名，姓名映射为显示名，部门直接映射，岗位按“岗位到角色”规则映射 | 账号创建成功，角色按岗位赋予，账号状态为启用 | 新员工首次单点登录成功，账号资料与目录一致 |
| 岗位变更 | 岗位字段由“开发工程师”改为“技术负责人”，部门不变 | 岗位映射规则重新计算角色，部门字段同步 | 角色更新，历史工作数据保留，账号状态不变 | 变更后登录，确认角色已更新且原有权责范围内的数据仍可访问 |
| 离职停用 | 在职状态改为“离职”，目录侧禁用账号 | 同步任务识别状态变化，触发平台侧停用 | 账号状态改为停用，会话失效 | 用该账号尝试登录应被拒绝；检查是否存在残留的启用账号 |
这个示例中有两个设计要点值得注意。第一，角色由岗位映射而来，岗位变更时角色自动重算，避免人工逐个调整。第二，离职停用依赖“在职状态”这一个字段作为触发条件，而不是依赖多个字段的组合判断，这样规则简单、易于验证。停用时延需要在方案中写明，例如“目录停用后一个同步周期内平台侧完成停用”，并在验收时按此时延检查。
残留账号检查是离职情景中最容易被忽略的一步。除了主账号，还要检查是否存在通过其他方式创建的本地账号、测试账号或历史遗留账号。建议在验收清单中单列一项，由平台管理员定期核对。
完成检查：上线前必须逐项确认的清单
上线前的验收应逐项判断“通过或不通过”，并为每个通过项留存证据。以下清单可直接用于验收会议。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 登录与单点登录可用性 | 试点账号与首批用户均能通过单点登录进入平台，登录失败时有明确提示 | 登录测试记录、失败提示截图或日志 | 平台管理员 |
| 属性与角色映射正确性 | 必填字段全部正确传递，角色与目录组或岗位的对应关系与映射表一致 | 映射核对表、抽样账号比对记录 | 平台管理员、业务代表 |
| 离职停用时延与残留账号 | 停用在约定时延内完成，抽查无残留启用账号 | 停用时间记录、账号状态抽查结果 | 目录管理员、平台管理员 |
| 异常登录处理 | 属性缺失、账号不存在、目录不可用等异常有预期表现，不产生错误授权 | 异常场景测试记录 | 平台管理员 |
| 回退方案可执行 | 回退步骤经演练，责任人明确，回退后用户可正常登录 | 回退演练记录 | 平台管理员、安全与合规 |
| 证据留存与确认 | 以上证据归档，验收结论由负责人签字或书面确认 | 验收记录与确认意见 | 项目负责人 |
清单之外还有两项建议在切换后持续关注：一是同步任务的运行状态监控，失败告警要有人接收；二是定期抽查账号状态与目录的一致性，频率可按人员流动情况设定。身份与账号集成不是一次配置就结束的工作，目录结构、组织调整和人员流动都会持续影响映射规则，保持映射表和检查清单的更新，才能让集成长期稳定运行。
常见问题
权威身份源只能有一个吗？HR系统和AD都能改人员信息时怎么处理？
建议确定唯一权威源，其他系统只做补充或下游同步。如果HR系统和AD都能修改人员信息，需要明确以谁为准，并规定另一方的同步方向与频率，否则同一属性在两个系统出现不同值时，平台侧账号资料会反复变化。判断标准可以设为：唯一标识字段（如员工编号）只在权威源中生成和维护，其他系统引用而不改写。
SAML 2.0、OIDC和SCIM需要全部用上吗？
按场景组合即可。常见做法是用SAML 2.0或OIDC承担单点登录，用SCIM或定时同步承担账号的开通、变更与停用。只做登录打通、账号由人工创建，也能运行，但离职停用会依赖人工操作，时延和遗漏风险更高。选型时逐项核对目标平台的实际配置项，本篇不给出具体产品的兼容版本结论。
离职停用后，平台上的历史工作数据会一起消失吗？
停用账号与处理历史数据是两件事。停用解决的是“该账号不能再登录、会话失效”，历史工作数据（如已提交的需求、文档、记录）通常需要保留并考虑归属转移。建议在方案中单独写明停用后数据的处理方式，例如由直属上级或指定接手人承接，并在验收清单中增加一项核对，避免停用后出现无人负责的工作项。
试点账号验证通过后，可以直接全量切换吗？
建议分批切换，每批保留观察期。试点账号覆盖的是有限情景，全量用户中可能存在外包人员、离职再入职、多部门兼任等特殊情况。分批切换时保留旧登录方式作为过渡，并提前演练回退步骤，明确回退开关的操作人和顺序。首批切换稳定运行约定观察期后，再推进下一批。
集成上线后，还需要持续维护哪些内容？
至少两类工作要持续做：一是同步任务的运行状态监控，失败告警需要有明确接收人；二是定期抽查账号状态与目录的一致性，频率可按人员流动情况设定。组织调整、岗位名称变化和目录字段新增都会影响映射规则，映射表和验收清单应随这些变化更新，否则集成会在几个月后逐渐失真。
