研发平台接入SSO前，需要把身份信息分成四类确认清楚：身份源与协议、账号唯一标识与匹配规则、随登录下发的用户属性、账号生命周期与异常处置口径。这四类信息整理成一份可评审的接入确认清单，明确每项由谁确认、产出什么文档，再进入联调配置，能减少上线后反复补字段、改匹配规则的情况。
要点总览（TL;DR）
- 接入前把身份信息分成四类确认：身份源与协议、账号唯一标识与匹配规则、随登录下发的用户属性、账号生命周期与异常处置口径。
- 协议与元数据要锁定到Entity ID、回调地址、签名证书有效期和环境划分，测试与生产分别注册应用。
- 主键优先选企业内部长期不变且全局唯一的字段，并写明匹配顺序、一人多账号和外包人员的处理方式。
- 属性清单逐字段标注来源、必填性和缺失处理，生命周期事件与异常排查责任到人。
- 全部检查项通过并留有记录后再进入联调，测试环境验证通过后才切生产。
先确认身份源、协议与信任关系
身份源与协议决定后续所有配置方式，接入前应先把这部分锁定。需要确认企业使用的身份提供方是哪一个系统、由哪个团队管理，以及研发平台侧由谁对接。如果企业有多个身份源（例如集团统一身份平台与事业部自建目录并存），要明确本次接入以哪一个为准，避免联调时出现两套认证入口。
协议选型需要双方共同确认。常见方式是SAML 2.0或OIDC，两者在元数据交换、令牌格式和登出处理上存在差异。研发平台侧支持哪些协议、支持到什么程度，应以该平台的实际文档或厂商确认为准，不能凭经验假设。协议一旦确定，后续的元数据项、证书和回调地址都围绕它展开。
元数据交换是信任关系落地的关键。需要收集并核对以下内容：
- 身份提供方的Entity ID或Issuer，以及研发平台侧的服务标识；
- 研发平台侧的ACS地址（SAML）或回调地址（OIDC），需区分测试与生产；
- 签名证书及其有效期，包括证书轮换时的过渡安排；
- 单点登出地址（如启用），以及登出后会话如何失效。
测试与生产两套环境通常需要分别注册应用，各自持有独立的元数据与证书。若共用一套配置，测试阶段的调试操作可能影响生产登录，因此环境划分应在确认表中单独列出。完成标志是形成一张身份源与协议确认表，包含元数据项、证书有效期、环境划分和双方对接人。
确定账号唯一标识与匹配规则
唯一标识决定“登录进来的人对应研发平台里的哪个账号”，是接入中最容易出问题的环节。候选主键通常有邮箱、工号、域账号和手机号，选择时要同时看稳定性和唯一性：邮箱可能因部门调整变更，手机号可能被回收再分配，工号在多数企业内相对稳定但外包人员可能没有。建议优先选择企业内部长期不变且全局唯一的字段，并明确该字段在身份源中的来源系统。
存量账号的匹配需要定好顺序。研发平台在接入前往往已有本地账号，首次SSO登录时要决定按什么顺序匹配：先按主键精确匹配，匹配不到再按备用字段匹配，仍匹配不到则进入待处理队列。一人多账号、重名、历史遗留账号是常见冲突，需要提前列出处理方式，例如合并、保留主账号并停用其余账号，或由管理员人工确认。
首次登录是自动创建账号还是依赖预先同步，取决于研发平台自身能力，接入前应向平台方核实。若支持自动创建，要确认创建时写入哪些属性、默认归属哪个组织；若依赖同步，则要确认同步任务的频率和失败重试机制。
离职、转岗、外包与共享账号需要单独约定标识口径。离职账号应在身份源停用后同步失效；转岗人员的主键若发生变化，要有映射或迁移方案；外包人员是否纳入统一身份源、使用何种标识，需与用工管理方确认；共享账号原则上应有独立标识或明确禁用，避免无法追溯操作人。完成标志是形成账号匹配规则说明，包含主键、匹配顺序、冲突处理和例外清单。
梳理随登录下发的用户属性
属性清单决定登录后研发平台能拿到哪些用户信息，以及这些信息用于什么。基础属性通常包括姓名、邮箱、工号、部门、岗位和账号状态。每项属性要标注用途：姓名和邮箱用于展示与通知，部门和岗位可能作为组织映射或后续权限分组的数据来源，账号状态用于判断是否允许登录。
必填与选填需要明确划分。必填属性缺失时，是阻断登录、使用默认值，还是允许登录但标记待补充，要有统一策略。例如部门缺失可能导致组织映射失败，此时可以选择阻断并提示联系管理员；而岗位缺失只影响展示，可以给默认值。属性缺失的处理方式应与业务方确认，避免上线后大量账号因缺字段无法登录。
属性变更后的同步时机也要定下来。常见做法是每次登录时刷新属性，或通过定时同步任务更新。登录时刷新的实时性好，但依赖用户再次登录；定时同步覆盖全量，但有延迟。两者可以结合使用，并明确以哪一方为准。
| 字段 | 来源 | 必填性 | 用途 | 缺失处理 |
|---|---|---|---|---|
| 姓名 | 身份源 | 必填 | 展示 | 阻断登录 |
| 邮箱 | 身份源 | 必填 | 通知、备用匹配 | 阻断登录 |
| 工号 | HR系统 | 必填 | 主键候选 | 阻断登录 |
| 部门 | HR系统 | 必填 | 组织映射 | 阻断并提示 |
| 岗位 | HR系统 | 选填 | 展示 | 留空 |
| 账号状态 | 身份源 | 必填 | 登录判断 | 按停用处理 |
完成标志是形成用户属性清单，逐字段写明字段名、来源、必填性、用途和缺失处理。
明确账号生命周期与异常处置口径
前几节确认的是静态信息，这一节处理运行期事件。账号的创建、变更、停用和删除，需要明确由哪一方触发：通常由身份源在人员入转调离时触发，研发平台侧接收并执行。责任方要写到具体团队，例如身份管理团队负责在身份源中维护状态，研发平台管理员负责确认同步结果。
异常处置要提前分工。登录失败可能来自证书过期、属性缺失、时钟偏差或匹配规则冲突，排查时需要知道先找谁。建议按现象列出排查顺序和责任人：证书问题由身份管理方检查有效期与轮换记录，属性问题由平台管理员核对下发内容，时钟偏差由双方运维确认时间同步配置。
紧急停用与批量回收需要预设操作路径。例如出现账号泄露风险时，能否在身份源一键停用并让研发平台会话失效；批量回收（如项目结束、外包退场）走什么流程、由谁审批。这些路径应在接入前演练或至少确认可行。
日志留存与审计字段也要约定。至少记录登录时间、账号标识、结果和失败原因，保留期限按企业合规要求确定。完成标志是形成生命周期与异常处置对照表，逐事件写明触发方、动作和责任人。
角色分工与交付物清单
确认内容需要落到人。接入准备阶段通常涉及四类角色：身份管理方负责身份源配置、元数据和证书；研发平台管理员负责平台侧应用注册、账号匹配和属性映射；安全与合规负责审核主键选择、日志留存和停用机制；业务代表负责确认属性用途和例外人员处理。小团队中一人可兼多角，但职责要写清楚。
每类确认信息应有评审和签字方式。协议与元数据由双方技术负责人确认，主键与匹配规则由业务和安全共同确认，属性清单由业务代表确认，生命周期与异常处置由运维和安全确认。评审可以采用会议纪要加确认表签字的形式，确认表本身要有版本号和变更记录，后续调整时能追溯是谁在什么时候改了什么。
在账号与成员管理环节，ONES提供成员管理能力，可承载组织架构与成员信息，便于研发平台在接入后按组织维护成员归属。具体支持方式以实际部署和配置为准。
完成标志是形成角色职责表与接入确认清单模板，模板中包含上述四类信息的填写栏位和确认人签名栏。
一个接入确认的填写示例
以下为演示情景，用于说明清单如何填写，不代表真实项目结论。某研发团队以企业统一身份平台为IdP接入研发平台，测试与生产分别注册应用。
协议部分填写：身份提供方为企业统一身份平台，管理归属为集团IT身份团队；协议选用OIDC，研发平台侧支持情况已向平台方确认；回调地址测试环境与生产环境各一个；签名证书有效期至次年某月，轮换提前一个月启动。
主键部分填写：主键选用工号，来源为HR系统；匹配顺序为先工号、再邮箱；一人多账号的处理方式为保留工号对应主账号，其余账号由管理员确认后停用；外包人员使用合作方编码加前缀作为工号，纳入统一身份源管理。
属性部分填写：姓名、邮箱、工号、部门、账号状态为必填，岗位为选填；部门缺失时阻断登录并提示联系管理员；属性在每次登录时刷新，每日另有一次全量同步兜底。
生命周期部分填写：入转调离由HR系统触发身份源状态变更，身份管理团队负责，研发平台管理员每日核对同步结果；证书过期由身份管理团队监控；紧急停用通过身份源停用账号并在平台侧确认会话失效。
示例中暴露的待确认项包括：外包人员编码规则尚未最终确定，需与用工管理方确认；生产环境证书轮换窗口与业务高峰期冲突，需调整时间。这两项列入待办，明确责任人和完成时间后再进入联调。
接入前的完成检查
以下检查项可作为进入联调的门槛，逐项判断是否通过，并指定负责人。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 协议与元数据 | 协议已确认，Entity ID、回调地址、证书及有效期在确认表中齐全 | 双方技术负责人 |
| 环境划分 | 测试与生产分别注册应用，配置互不影响 | 研发平台管理员 |
| 主键与匹配规则 | 主键、匹配顺序、冲突处理和例外清单经业务与安全确认 | 业务代表、安全 |
| 属性清单 | 必填项齐全，缺失处理明确，同步时机已约定 | 业务代表、平台管理员 |
| 生命周期与异常处置 | 事件、触发方、动作、责任人逐项到人 | 身份管理方、运维 |
| 测试环境验证 | 登录、登出、属性下发、停用场景验证通过 | 平台管理员 |
| 生产切换 | 测试通过并完成回退方案确认后再切生产 | 项目负责人 |
全部检查项通过并留有记录后，再进入联调配置。确认清单随变更更新版本，作为后续审计和问题排查的依据。
常见问题
身份源有多个系统并存时，接入前怎么确定以哪个为准？
先确认本次接入的认证入口是哪一个系统，并明确该系统的管理团队和对接人。集团统一身份平台与事业部自建目录并存时，常见做法是以集团平台作为唯一认证入口，事业部目录作为属性来源或后续同步对象。需要把这一决定写进确认表，同时说明其他身份源在本次接入中承担什么角色，避免联调阶段出现两套登录入口。
存量账号和SSO账号对不上，应该先处理哪一类冲突？
优先处理影响登录的冲突，再处理历史遗留。按主键精确匹配失败、一人多账号、重名这三类会直接导致登录后进入错误账号或无法登录，应在联调前由业务方逐条确认处理方式。历史遗留的长期未使用账号可以列入例外清单，约定停用或保留的规则，不必在接入前全部清理完毕，但要有明确的责任人和时间点。
属性缺失时阻断登录，会不会导致上线初期大量用户无法登录？
阻断策略要结合属性用途判断。用于组织映射或登录判断的必填属性缺失时，阻断并提示联系管理员可以避免脏数据进入平台；仅用于展示的属性缺失，给默认值或留空更合适。上线前可以先对身份源做一次属性完整性抽查，统计缺失比例，再决定哪些字段设为阻断、哪些设为告警。阻断提示中应写明联系人和补充路径。
测试环境验证通过后，切生产还需要确认什么？
生产环境有独立的元数据、证书和回调地址，需要确认这些配置已单独注册并核对无误。证书有效期和轮换窗口要避开业务高峰期，回退方案要写明：出现登录异常时如何切回原登录方式、由谁决策、在多长时间内完成。生产切换后先小范围验证登录、登出、属性下发和停用场景，再逐步放开。
小团队没有独立的身份管理团队，角色分工怎么简化？
可以一人兼多角，但确认内容不能省。把四类信息的确认人写清楚即可：协议与元数据由负责身份源配置的人确认，主键与匹配规则由了解人事数据的人确认，属性清单由使用研发平台的业务负责人确认，生命周期与异常处置由运维确认。评审可以用一份确认表加简短记录完成，关键是每项有明确的责任人和确认时间，后续调整时能追溯。
