📚 课程目录第4章身份提供者与依赖方的信任配置

4. 身份提供者与依赖方的信任配置

在身份联邦中，IdP（Identity Provider，身份提供者）与 SP（Service Provider，依赖方）之间的信任不是自动产生的，而是通过一组显式配置建立起来的。可以把这段信任关系理解为一份“数字合同”：IdP 承诺“我签发的断言是可信的”，SP 承诺“我接受来自这个 IdP 的断言，并按其中的属性做授权”。这份合同能否生效，取决于三个关键要素——信任关系配置、属性释放策略、断言签名与加密。本节围绕这三要素展开，并最终落地为一个可运行的最小联邦信任对。

信任关系的三个支点

信任关系配置解决的是“谁信任谁”。在 SAML 场景中，IdP 与 SP 通过交换元数据（Metadata）互相声明身份：IdP 元数据包含实体 ID、SSO 端点、签名证书；SP 元数据包含实体 ID、ACS（Assertion Consumer Service）端点、期望的 NameID 格式。双方各自把对方元数据导入本地配置，就形成了双向信任锚点。在 OIDC 场景中，等价物是 issuer、client_id、client_secret 与 redirect_uri 的登记。

属性释放策略解决的是“释放什么”。IdP 通常持有用户的大量属性（姓名、邮箱、部门、角色、工号），但不应无条件全部释放给每个 SP。最小权限原则要求按 SP 逐个配置属性白名单，例如给报销系统只释放 employee_id 与 department，给代码仓库释放 email 与 groups。属性释放策略是联邦中隐私与合规的第一道闸门。

断言签名与加密解决的是“怎么保证可信与保密”。签名保证断言在传输中未被篡改、且确实由持有私钥的 IdP 签发；加密保证断言内容即使被截获也无法读取。二者共同构成断言的完整性与机密性保护。

断言签名与加密的配置要点

签名配置的核心是算法与密钥。推荐使用 RSA-2048 以上密钥配合 SHA-256 摘要算法，避免已不安全的 SHA-1。IdP 用私钥对断言签名，SP 用预先导入的 IdP 公钥证书验签。若验签失败，SP 必须拒绝该断言，而不是降级放行——这是联邦安全中不可妥协的一条底线。

加密配置则用于保护断言中的敏感属性。IdP 使用 SP 的公钥加密断言，只有持有对应私钥的 SP 才能解密。加密是可选的，但当断言包含工号、部门、角色等内部属性时，建议开启。需要注意的是，加密与签名可以同时使用，典型顺序是“先签名后加密”：IdP 先对断言签名，再用 SP 公钥加密整个断言，SP 收到后先解密再验签。

实战：配置一个最小联邦信任对

下面以一个 SAML 最小信任对为例，IdP 使用 https://idp.corp.example，SP 使用 https://app.corp.example。目标是让用户从 SP 发起登录，经 IdP 认证后携带 email 与 department 两个属性返回 SP 并成功建立会话。

第一步：生成密钥与证书。IdP 侧生成签名密钥对，SP 侧生成加密密钥对（若启用加密）。

# IdP 签名密钥
openssl req -x509 -newkey rsa:2048 -keyout idp-sign.key \
  -out idp-sign.crt -days 365 -nodes \
  -subj "/CN=idp.corp.example"

# SP 加密密钥（可选）
openssl req -x509 -newkey rsa:2048 -keyout sp-enc.key \
  -out sp-enc.crt -days 365 -nodes \
  -subj "/CN=app.corp.example"

第二步：互换元数据。IdP 元数据中声明实体 ID、SSO 端点与签名证书；SP 元数据中声明实体 ID、ACS 端点与期望的 NameID 格式。双方各自导入对方元数据，形成信任锚点。

<EntityDescriptor entityID="https://idp.corp.example">
  <IDPSSODescriptor>
    <KeyDescriptor use="signing">
      <X509Certificate>MIID...idp-sign.crt...</X509Certificate>
    </KeyDescriptor>
    <SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://idp.corp.example/saml2/sso"/>
  </IDPSSODescriptor>
</EntityDescriptor>

第三步：配置属性释放策略。在 IdP 侧为 SP 建立属性白名单，只释放 email 与 department，其余属性一律不释放。这一步直接决定了断言中会出现哪些属性。

# 属性释放策略（伪配置）
sp: https://app.corp.example
release:
  - email
  - department
nameid_format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

第四步：配置签名与加密。IdP 侧启用断言签名，算法 RSA-SHA256；若启用加密，则导入 SP 加密证书，对断言整体加密。SP 侧导入 IdP 签名证书用于验签，并加载自身加密私钥用于解密。

第五步：验证信任对。从 SP 发起登录，观察以下判断点：SP 是否正确重定向到 IdP 的 SSO 端点；IdP 认证后返回的断言是否包含 email 与 department；SP 验签是否通过；解密后属性是否正确映射到本地会话。若验签失败，检查 SP 侧导入的 IdP 证书是否与 IdP 当前签名证书一致；若属性缺失，检查 IdP 属性释放白名单是否包含该属性。

最小信任对验证通过后，建议立即做一次“负向测试”：故意篡改断言中的一个字符，确认 SP 会因验签失败而拒绝登录。这能验证签名校验确实生效，而不是被跳过。

常见配置错误与排查方向

实践中，信任对配置失败往往集中在几类问题上。实体 ID 不一致会导致元数据匹配失败；ACS 端点与 SP 实际接收地址不符会导致断言投递失败；证书过期或导入错误会导致验签失败；属性释放策略未包含目标属性会导致 SP 收到空属性。排查时应按“元数据匹配 → 端点可达 → 证书有效 → 属性释放 → 验签解密”的顺序逐层确认，而不是盲目修改配置。

信任配置的本质，是把“谁信任谁、释放什么、如何保证可信”这三件事用可验证的配置固定下来。一个最小联邦信任对跑通之后，后续扩展更多 SP 或接入更多属性，都只是在这套结构上做增量，而不是重新设计信任模型。