研发平台SSO单点登录，是指研发人员用企业统一身份账号登录一次，就能访问代码托管、需求管理、流水线、制品库等多个研发系统的一种身份认证方式。它的核心是把“验证你是谁”的工作交给企业统一身份提供方，研发平台作为服务方信任该认证结果，从而免去各系统分别建账号、分别输密码。本文围绕身份认证与账号打通展开，说明SSO的组成、流程与职责边界。
要点总览（TL;DR）
- 研发平台SSO单点登录，是把身份核验交给企业统一身份提供方（IdP）、研发平台作为服务提供方（SP）信任认证结果的一种身份认证方式，用户认证一次即可访问多个研发系统。
- 一次登录包含发起访问、跳转认证、返回凭证、建立会话四个环节；研发平台通常对接企业目录、AD/LDAP、统一身份认证平台等身份源。
- SSO只回答“你是谁”，不回答“你能做什么”。项目角色、字段权限、文档可见范围属于授权策略，需要单独配置，账号打通与权限同步是两件事。
- SSO与统一登录页、目录同步、MFA、权限治理分工不同：登录页是界面形态，目录同步提供账号来源，MFA在IdP侧叠加，权限治理是独立层次。
- 离职停用后，认证入口会拒绝访问，但平台内已分配的项目角色和数据仍需在成员管理环节单独处理。
SSO在研发平台里到底指什么
SSO的英文全称是Single Sign-On，中文通常译为“单点登录”。这里的“单点”指认证动作只发生一次，“登录”指获得访问多个系统的会话资格。研发平台语境下，SSO描述的是一种信任关系：企业统一身份系统负责核验用户身份，研发平台接受这个核验结果，不再要求用户单独输入一套平台密码。
理解SSO需要先分清两个角色。身份提供方（Identity Provider，简称IdP）是负责认证的一方，常见形态包括企业目录服务、统一身份认证平台或云身份服务。服务提供方（Service Provider，简称SP）是接受认证结果、提供业务功能的一方，研发平台及其下属的代码托管、需求管理、流水线等系统通常都处于SP位置。一次登录能够成立，前提是SP信任IdP签发的认证结果，这种信任一般通过双方预先配置的对接关系建立。
一次典型的SSO登录可以拆成四个环节：
- 发起访问：用户在浏览器中打开研发平台的某个地址，平台发现当前没有有效会话，于是把请求转向IdP。
- 跳转认证：用户在IdP页面完成身份核验，可能是输入企业账号密码，也可能叠加短信、动态口令等二次验证。
- 返回凭证：IdP认证通过后，向研发平台返回一个认证凭证或断言，声明“该用户身份已核实”。
- 建立会话：研发平台校验凭证有效后，为用户建立本地会话，后续访问同一平台下的其他系统时直接复用该会话。
研发平台作为SP时，对接的身份源通常来自企业已有的账号体系。常见来源包括企业人力资源系统同步的组织与人员数据、微软AD或LDAP目录、企业统一身份认证平台，以及部分企业采用的云办公平台身份服务。选择哪种身份源，取决于企业当前人员账号的权威数据存放在哪里。
SSO管什么、不管什么：认证与授权的边界
SSO的职责范围可以用一句话概括：它回答“你是谁”，不回答“你能做什么”。认证（Authentication）确认访问者身份的真实性，授权（Authorization）决定该身份可以访问哪些资源、执行哪些操作。SSO属于前者，权限策略属于后者，两者在概念上分属不同层次。
SSO能够解决的问题集中在账号与登录环节：
- 账号统一：研发人员在各研发系统使用同一身份标识，减少多套账号并存带来的对应困难。
- 密码减少：用户只需在IdP处完成一次认证，不必为每个研发系统分别记忆和输入密码。
- 登录入口收敛：多个系统的认证入口集中到企业统一身份侧，登录行为更便于集中管理。
- 离职停用生效：员工离职后在IdP侧停用账号，后续通过SSO发起的访问会因认证失败而被拒绝。
SSO不负责的内容同样需要明确：项目角色分配、字段级权限、文档可见范围、数据行级过滤，这些都属于授权策略范畴。一个用户通过SSO成功登录研发平台，只说明身份可信，并不意味着他自动获得某个项目的编辑权或某份文档的查看权。账号打通与权限同步是两件事，前者由SSO完成，后者往往需要配合用户目录同步、组织架构映射或角色映射规则来实现。把SSO接入当成权限配置的替代方案，是实施中最常见的预期偏差。
研发平台SSO的常见实现方式与组成
SSO不是单一技术，而是一组机制的组合。判断一个研发平台的SSO方案形态，可以从协议、账号来源、会话管理和登出行为四个维度观察。
协议层面，常见选择各有定位。SAML以XML格式传递认证断言，在企业级身份对接中应用广泛，适合与成熟的身份平台集成。OAuth 2.0本身是授权框架，OpenID Connect在其之上补充了身份认证层，二者组合在互联网形态的应用中较为常见。CAS是较早出现的单点登录协议，结构相对简单，在部分高校和传统企业环境中仍有使用。LDAP严格来说不是SSO协议，而是目录访问协议，常被用作账号来源或认证后端，与SSO配合使用。
| 机制维度 | 常见形态 | 主要作用 |
|---|---|---|
| 认证协议 | SAML、OAuth 2.0/OpenID Connect、CAS | 规定IdP与SP之间如何传递认证结果 |
| 账号来源 | 目录同步、即时创建 | 决定研发平台中的用户记录从何而来 |
| 会话管理 | 平台本地会话、票据复用 | 维持登录状态，减少重复认证 |
| 单点登出 | SLO（Single Logout） | 一处登出后通知各系统结束会话 |
账号来源有两种思路。目录同步指定期或实时从企业目录拉取人员数据，在研发平台内预先建立用户记录，用户首次登录时直接匹配已有记录。即时创建指用户首次通过SSO登录时，平台根据认证断言中的信息自动建立用户记录。前者便于提前配置组织关系，后者上手更快，但对断言字段的完整性依赖更高。
会话与单点登出（SLO）是容易被忽略的部分。用户登录后，研发平台通常维护一个本地会话，会话有效期决定多久需要重新认证。单点登出指用户在任一系统主动退出时，通过协议通知其他已登录系统一并结束会话。多系统串联时，信任关系往往呈链式结构：研发平台作为SP信任IdP，平台内的子系统再信任平台，凭证在链路上逐级传递，任一环节的信任配置缺失都会导致登录中断。
容易混淆的相邻概念：SSO、统一登录页、账号同步、权限治理
几个概念经常被混用，实际分工差别明显。统一登录页是界面形态，把多个系统的登录入口放在同一页面，用户仍需分别输入各系统账号；SSO是认证机制，用户完成一次认证后即可访问多个系统。有统一登录页不等于实现了SSO，反之SSO也不必然表现为一个聚合页面。
SSO与LDAP/AD目录同步的关系是配合而非替代。目录同步解决“研发平台里有没有这个人的账号、组织信息是否正确”，SSO解决“登录时由谁核验身份”。实践中常见组合是：通过目录同步预先建立账号与组织关系，通过SSO完成登录认证，两者共同支撑账号统一。
多因素认证（MFA）与SSO是叠加关系。MFA在认证环节增加一层验证因素，提升身份核验强度；SSO决定认证发生在哪里、结果如何传递给各系统。企业可以在IdP侧统一启用MFA，使所有接入SSO的研发系统共享这一强度，而不必在每个系统单独配置。
| 概念 | 解决的问题 | 与SSO的关系 |
|---|---|---|
| SSO单点登录 | 一次认证访问多个系统 | 本体 |
| 统一登录页 | 登录入口集中展示 | 界面形态，可独立存在 |
| LDAP/AD目录同步 | 账号与组织数据来源 | 常作为账号来源配合使用 |
| 多因素认证 | 提升身份核验强度 | 可在IdP侧叠加 |
| 权限治理 | 决定可访问的资源与操作 | 独立层次，SSO不覆盖 |
权限治理包括研发平台内的项目角色、操作权限，也包括知识文档的可见范围与共享策略。这些内容由平台自身的权限模型管理，SSO只提供可信的身份输入。把身份认证做扎实，权限治理才有稳定的对象基础；但认证完成之后，谁属于哪个项目、能编辑哪些文档，仍需单独配置和定期复核。
在账号统一与成员停用这两个管理动作上，ONES提供组织成员管理与账号相关能力，可承接企业身份体系同步过来的人员信息，并在成员离职或状态变更时影响其平台访问。这类能力处理的是账号生命周期，与SSO的认证环节衔接，权限分配仍需在项目与文档层面单独设置。
一个具体例子：新员工与离职员工的登录路径
以下为说明机制而构造的演示情景，用于展示SSO在研发平台中的实际作用路径。
新员工入职后，人力资源系统将其信息写入企业目录，目录同步把该员工加入研发平台的成员列表，并归入相应组织。员工首次打开研发平台地址时，平台检测到无有效会话，跳转至企业IdP；员工输入企业账号并完成二次验证，IdP返回认证断言；平台校验通过后建立会话，员工进入工作台。此时他能看到哪些项目，取决于管理员是否已为其分配项目角色，SSO本身不完成这一步。若企业采用即时创建模式，则首次登录时平台依据断言自动建立成员记录，组织归属可能需要在登录后补充或由断言字段映射。
离职场景的路径相反。员工离职后，管理员在IdP侧停用其账号，该员工再次访问研发平台时，跳转认证环节即被IdP拒绝，无法获得新的认证断言，平台也就无法建立会话。已经存在的会话会在有效期届满或单点登出通知到达时失效。这条路径说明SSO让停用动作在认证入口处生效，但平台内已分配的项目角色和数据不会因认证失败而自动清理，仍需在成员管理环节做停用或移除处理。
两个常见误解值得纠正。其一，认为接入SSO就自动完成项目权限分配。SSO只保证登录者身份可信，项目成员资格、角色和文档权限需要另行配置，通常还要建立入职、转岗、离职对应的权限变更流程。其二，认为SSO等于所有系统共用一个密码。SSO的实际效果是密码只在IdP处使用一次，各研发系统不再各自保存密码；用户凭据集中在一处，也意味着IdP侧的安全策略（如密码强度、MFA）会影响全部接入系统，这既是便利也是需要重点防护的集中风险点。
常见问题
企业已经有统一登录页，还需要做SSO吗？
两者解决的不是同一个问题。统一登录页把多个系统的入口集中到一个页面，用户点进去后往往仍要分别输入各系统账号；SSO是在认证机制层面完成一次核验，再把结果传递给各系统。如果目标是减少重复输入密码、让离职停用在认证入口生效，仅做统一登录页不够，需要实现SSO对接。反过来，SSO也不必然表现为一个聚合页面，用户从任一系统入口进入都可能触发跳转认证。
接入SSO后，新员工的项目权限会自动配好吗？
不会。SSO只保证登录者身份可信，项目成员资格、角色和文档权限属于授权策略，需要另行配置。常见做法是把权限分配嵌入入职流程：账号由目录同步或首次登录建立后，由项目管理员按岗位模板分配角色；转岗时同步调整，离职时在成员管理环节停用或移除。若企业希望减少手工操作，可以配合组织架构映射或角色映射规则，但这仍属于权限治理范畴，与SSO认证是两件事。
SSO和LDAP、AD目录同步是什么关系，需要二选一吗？
两者通常配合使用，不构成替代关系。目录同步解决研发平台里有没有这个人的账号、组织信息是否正确，为平台提供账号与组织数据来源；SSO解决登录时由谁核验身份。实践中常见组合是先用目录同步预先建立账号与组织关系，再通过SSO完成登录认证。只做目录同步而不做SSO，用户可能仍需在各系统分别登录；只做SSO而不做目录同步，则依赖认证断言中的字段是否足够完整来建立用户记录。
在IdP侧启用多因素认证，会影响所有接入SSO的研发系统吗？
会。MFA与SSO是叠加关系：MFA在认证环节增加一层验证因素，SSO决定认证发生在哪里、结果如何传递给各系统。企业如果在IdP侧统一启用MFA，所有信任该IdP的研发系统都会共享这一认证强度，不必在每个系统单独配置。这也意味着IdP侧的安全策略（密码强度、MFA要求、账号停用规则）会影响全部接入系统，集中管理带来便利的同时，IdP本身成为需要重点防护的环节。
员工离职后，SSO能保证他立刻无法访问研发平台内的所有数据吗？
SSO能保证的是认证入口处生效：IdP停用账号后，该员工再次发起访问会在认证环节被拒绝，无法获得新的认证断言，也就无法建立新会话。已经存在的会话会在有效期届满或单点登出通知到达时失效。但平台内已分配的项目角色、历史数据和文档权限不会因认证失败而自动清理，仍需在成员管理环节做停用或移除处理，并按需复核其名下工作项的交接。把停用动作同时覆盖IdP与平台成员管理，才能形成完整的离职处理闭环。
