---
title: 使用你的 IdP 登录
description: 让外部连接派上用场——在应用上以登录按钮提供你的身份提供方，或强制某个已验证域名的用户都走它。
editUrl: true
head: []
template: doc
sidebar:
  order: 5
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

import { CardGrid, LinkCard } from "@astrojs/starlight/components";

注册好一个[外部连接](/zh-cn/domains-federation/federation-connectors/)之后，有**两种**方式让它派上用场。它们共享同一个外部连接、同一套登录机制、同一套账户模型——区别只在于*由谁来决定*用户要走你的 IdP。

| 模式 | 由谁开启 | 影响谁 |
|---|---|---|
| **应用级管理** | 应用开发者，按应用 | 在该应用上选择「使用 …… 登录」按钮的任何人 |
| **域级管理（强制 SSO）** | 域名所有者，通过登录策略 | 某个已验证域名下的每一个账户，对每个应用生效，无法退出 |

两者都是**第一层认证方法**，因此它们与[三层规则模型](/zh-cn/application-rules/overview/)的其余部分组合的方式，和任何其他方法别无二致。

## 应用级登录

这是直截了当的「让我应用的用户用我们公司的 IdP 登录」场景。在一个你组织拥有的应用上，添加一条第一层认证规则：

```json
{
  "method": "ENTERPRISE_FEDERATION_APPLICATION_MANAGED",
  "payload": { "connectorAnchor": "Bastion-K7Q2-M9XB-3FNP-Covenant" }
}
```

- `connectorAnchor` 必须引用一个**归该应用所属组织所有**的外部连接——这一点在保存规则时强制校验。
- Sudomimus 会在认证界面渲染一个**「使用 `<外部连接显示名称>` 登录」**按钮。
- 一条规则 = 一个按钮。要提供多个 IdP，就添加多条规则（它们之间是 OR 关系，和任何第一层规则一样）。

当用户点击该按钮时，浏览器会被重定向到你的 IdP，带着授权码返回（浏览器驱动的 PKCE），随后 Sudomimus 运行**与其他每一种登录方法相同的 realize 流水线**：账户关联决策、身份行写入、第二层 realize、同意闸门、令牌签发。在下游，联合登录没有任何特殊之处——它产出的是一个普通的 Sudomimus 会话。

### 联合身份如何关联到账户

当你的 IdP 返回一个用户时，Sudomimus 决定如何把他们挂接上去，方式与消费级 OAuth 提供方完全一致：

1. **之前见过该外部连接的 subject** → 复用已有账户（可应对用户在 IdP 侧更换邮箱）。
2. **IdP 断言了一个与已有账户匹配的已验证邮箱** → 把该外部连接关联到那个账户。
3. **两者都不是** → 创建一个新账户。

由于关联键是**按外部连接**命名空间隔离的，一个 Sudomimus 账户可以跨不同外部连接持有多个联合身份——通过两个恰好都使用邮箱 `jordan@acme.example` 的不同 IdP 登录，会经由第 2 步解析到同一个账户。

## 强制 SSO（域级管理）

这是企业 SSO 的最终成果：你所拥有域名下的**每一个**用户都只能走你的 IdP 登录——通行密钥、邮箱 OTP、消费级 OAuth 都被从他们手里拿走。它由两块你已经认识的东西搭成：

1. 一个已验证域名，其[登录策略](/zh-cn/domains-federation/domain-login-policy/)被设为 **`SSO_ONLY`**，并绑定到你组织的某个外部连接。
2. 每个同意接受这类登录的应用上，那个潜伏的第一层方法 **`ENTERPRISE_FEDERATION_DOMAIN_MANAGED`**：

   ```json
   {
     "method": "ENTERPRISE_FEDERATION_DOMAIN_MANAGED",
     "payload": {}
   }
   ```

负载是**空的**——与应用级管理不同，外部连接**不**在规则里指名。它在登录时由用户的邮箱域名解析得出：邮箱域名 → 已验证域名 → 绑定到该域名 `SSO_ONLY` 策略的那个外部连接。因此，驱动登录的可以是*另一个*组织的域名，而这正是重点所在：你的应用在说「我接受用户的域名所有者所要求的任何 IdP」。

### 被管控的用户会经历什么

- **邮箱优先的流程。** 当一个被 SSO 管控的用户输入邮箱时，Sudomimus 会压制其他所有方法，只提供「使用 `<外部连接>` 继续」这一条路径。
- **无邮箱的流程**（无用户名通行密钥、消费级 OAuth、Steam）。用户只有在认证*之后*才能被识别，因此 Sudomimus 会在 realize 时拦住他们、把他们重定向进 SSO 流程，并在第二趟完成登录。
- **是确认屏，而非静默跳转。** core-ui 会显示一个「使用 `<外部连接>` 继续」的屏幕，而不是自动重定向。被**两个**不同组织的 SSO 域名同时染色的账户（罕见）会得到一个**选择器**——任意一个被绑定的外部连接都能满足闸门。
- **新员工。** 一个邮箱位于强制-SSO 域名下的全新用户，会在首次登录时*经由* IdP 完成注册（registration-via-SSO）——不存在单独的注册步骤。

### 没有opt-in的应用

一个**没有**列出 `ENTERPRISE_FEDERATION_DOMAIN_MANAGED` 的应用，会直接**拒绝**一个被 SSO 管控的用户——不会有任何隐式的 SSO 逃生口被塞进一个并未主动要求它的应用。这保持了第一层的默认拒绝：强制 SSO 永远不会悄悄给某个应用添加一种方法。

:::note[强制 SSO 只覆盖第一层]
`SSO_ONLY` 只改变受管用户*可以使用的认证方式*，不会覆盖第二层或第三层规则。通过 SSO 完成认证的用户仍可能被应用的邮箱允许列表拒绝，认证结果也仍由该应用的返回规则交付。认证不等于授权。
:::

### 离职处理

由于强制执行发生在登录（realize）时，一个 IdP 账户已被停用的离职员工，根本无法再获取新的断言，也就无法再次登录。已经签发的令牌会按 TTL 过期（访问令牌 3 小时，刷新令牌 30 天）——这就是标准的 SSO 离职窗口，与 `BLOCK_ALL` 相同的「仅 realize」行为。

## 相关

<CardGrid>
<LinkCard
    title="外部连接"
    description="注册两种模式都要用到的 OIDC 身份提供方。"
    href="/zh-cn/domains-federation/federation-connectors/"
/>
<LinkCard
    title="域名登录策略"
    description="驱动域级强制 SSO 的 SSO_ONLY 策略。"
    href="/zh-cn/domains-federation/domain-login-policy/"
/>
<LinkCard
    title="第一层 — 认证规则"
    description="两种联合方法如何置于三层规则模型之中。"
    href="/zh-cn/application-rules/authentication-rules/"
/>
</CardGrid>