使用你的 IdP 登录
注册好一个外部连接之后,有两种方式让它派上用场。它们共享同一个外部连接、同一套登录机制、同一套账户模型——区别只在于由谁来决定用户要走你的 IdP。
| 模式 | 由谁开启 | 影响谁 |
|---|---|---|
| 应用级管理 | 应用开发者,按应用 | 在该应用上选择「使用 …… 登录」按钮的任何人 |
| 域级管理(强制 SSO) | 域名所有者,通过登录策略 | 某个已验证域名下的每一个账户,对每个应用生效,无法退出 |
两者都是第一层认证方法,因此它们与三层规则模型的其余部分组合的方式,和任何其他方法别无二致。
这是直截了当的「让我应用的用户用我们公司的 IdP 登录」场景。在一个你组织拥有的应用上,添加一条第一层认证规则:
{ "method": "ENTERPRISE_FEDERATION_APPLICATION_MANAGED", "payload": { "connectorAnchor": "Bastion-K7Q2-M9XB-3FNP-Covenant" }}connectorAnchor必须引用一个归该应用所属组织所有的外部连接——这一点在保存规则时强制校验。- Sudomimus 会在认证界面渲染一个「使用
<外部连接显示名称>登录」按钮。 - 一条规则 = 一个按钮。要提供多个 IdP,就添加多条规则(它们之间是 OR 关系,和任何第一层规则一样)。
当用户点击该按钮时,浏览器会被重定向到你的 IdP,带着授权码返回(浏览器驱动的 PKCE),随后 Sudomimus 运行与其他每一种登录方法相同的 realize 流水线:账户关联决策、身份行写入、第二层 realize、同意闸门、令牌签发。在下游,联合登录没有任何特殊之处——它产出的是一个普通的 Sudomimus 会话。
联合身份如何关联到账户
Section titled “联合身份如何关联到账户”当你的 IdP 返回一个用户时,Sudomimus 决定如何把他们挂接上去,方式与消费级 OAuth 提供方完全一致:
- 之前见过该外部连接的 subject → 复用已有账户(可应对用户在 IdP 侧更换邮箱)。
- IdP 断言了一个与已有账户匹配的已验证邮箱 → 把该外部连接关联到那个账户。
- 两者都不是 → 创建一个新账户。
由于关联键是按外部连接命名空间隔离的,一个 Sudomimus 账户可以跨不同外部连接持有多个联合身份——通过两个恰好都使用邮箱 [email protected] 的不同 IdP 登录,会经由第 2 步解析到同一个账户。
强制 SSO(域级管理)
Section titled “强制 SSO(域级管理)”这是企业 SSO 的最终成果:你所拥有域名下的每一个用户都只能走你的 IdP 登录——通行密钥、邮箱 OTP、消费级 OAuth 都被从他们手里拿走。它由两块你已经认识的东西搭成:
-
一个已验证域名,其登录策略被设为
SSO_ONLY,并绑定到你组织的某个外部连接。 -
每个同意接受这类登录的应用上,那个潜伏的第一层方法
ENTERPRISE_FEDERATION_DOMAIN_MANAGED:{"method": "ENTERPRISE_FEDERATION_DOMAIN_MANAGED","payload": {}}
负载是空的——与应用级管理不同,外部连接不在规则里指名。它在登录时由用户的邮箱域名解析得出:邮箱域名 → 已验证域名 → 绑定到该域名 SSO_ONLY 策略的那个外部连接。因此,驱动登录的可以是另一个组织的域名,而这正是重点所在:你的应用在说「我接受用户的域名所有者所要求的任何 IdP」。
被管控的用户会经历什么
Section titled “被管控的用户会经历什么”- 邮箱优先的流程。 当一个被 SSO 管控的用户输入邮箱时,Sudomimus 会压制其他所有方法,只提供「使用
<外部连接>继续」这一条路径。 - 无邮箱的流程(无用户名通行密钥、消费级 OAuth、Steam)。用户只有在认证之后才能被识别,因此 Sudomimus 会在 realize 时拦住他们、把他们重定向进 SSO 流程,并在第二趟完成登录。
- 是确认屏,而非静默跳转。 core-ui 会显示一个「使用
<外部连接>继续」的屏幕,而不是自动重定向。被两个不同组织的 SSO 域名同时染色的账户(罕见)会得到一个选择器——任意一个被绑定的外部连接都能满足闸门。 - 新员工。 一个邮箱位于强制-SSO 域名下的全新用户,会在首次登录时经由 IdP 完成注册(registration-via-SSO)——不存在单独的注册步骤。
没有opt-in的应用
Section titled “没有opt-in的应用”一个没有列出 ENTERPRISE_FEDERATION_DOMAIN_MANAGED 的应用,会直接拒绝一个被 SSO 管控的用户——不会有任何隐式的 SSO 逃生口被塞进一个并未主动要求它的应用。这保持了第一层的默认拒绝:强制 SSO 永远不会悄悄给某个应用添加一种方法。
由于强制执行发生在登录(realize)时,一个 IdP 账户已被停用的离职员工,根本无法再获取新的断言,也就无法再次登录。已经签发的令牌会按 TTL 过期(访问令牌 3 小时,刷新令牌 30 天)——这就是标准的 SSO 离职窗口,与 BLOCK_ALL 相同的「仅 realize」行为。