3. 信任边界的建立

在身份联邦中，信任边界不是一条物理防线，而是一组由元数据、证书、密钥和注册信息共同支撑的逻辑约定。两个实体之所以能互相信任，是因为它们各自持有可验证的凭据，并遵循同一套元数据语义。本节围绕“信任锚点”与“信任链”两个核心概念，说明如何通过元数据交换、证书与密钥管理、实体注册与发现，把分散的信任关系组织成可验证、可撤销、可扩展的信任网络。

信任锚点：信任链的起点

信任锚点（Trust Anchor）是信任链的根，通常表现为一个自签名根证书、一个受信任的元数据签名密钥，或一个被双方共同认可的权威注册机构。信任链的构建逻辑是：从信任锚点出发，逐级验证下级证书或元数据签名，直到确认目标实体的公钥和属性真实有效。以 SAML 联邦为例，身份提供者（IdP）与服务提供者（SP）各自持有签名密钥，双方通过交换包含公钥的元数据建立信任；若采用分层联邦，则根联邦运营方作为信任锚点，为下级成员签发元数据签名证书，形成“根—成员—实体”的信任链。

信任锚点的选择直接决定信任边界的范围。单锚点结构简单但存在单点失效风险；多锚点或交叉认证结构更健壮，但需要处理路径选择和策略冲突。实际部署中，常见做法是将根证书离线保存，仅用于签发中间 CA 或元数据签名证书，在线系统只持有中间证书，从而缩小攻击面。

元数据交换：把信任关系写成可验证的文档

元数据是信任边界的“说明书”。它通常以 XML 或 JSON 文档形式发布，包含实体标识（entityID）、公钥证书、签名算法、服务端点（如 SSO 地址、ACS 地址）、支持的绑定方式、属性需求以及联系人信息。元数据交换的关键在于“签名”：发布方用私钥对元数据签名，接收方用信任锚点验证签名，从而确认元数据未被篡改且来源可信。

以 SAML 元数据为例，一个 IdP 的元数据片段可能包含：

<EntityDescriptor entityID="https://idp.example.org">
  <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <KeyDescriptor use="signing">
      <ds:KeyInfo><ds:X509Data>
        <ds:X509Certificate>MIIC...</ds:X509Certificate>
      </ds:X509Data></ds:KeyInfo>
    </KeyDescriptor>
    <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://idp.example.org/sso"/>
  </IDPSSODescriptor>
</EntityDescriptor>

接收方拿到该文档后，先验证外层签名，再提取 X509Certificate 作为该 IdP 的签名公钥。此后 IdP 发出的 SAML 断言若用对应私钥签名，SP 即可用该公钥验证。元数据交换的常见方式包括：手动导入、通过元数据聚合器分发、或使用动态发现协议（如 SAML 的 Metadata Query Protocol）按需拉取。

证书与密钥管理：信任链的“材料”

证书和密钥是信任链的物理载体。证书把公钥与实体身份绑定，密钥则用于签名和加密。管理要点包括：

• 密钥生成与存储：签名私钥应在 HSM 或受控密钥库中生成，避免明文落盘。加密私钥与签名私钥建议分离，降低单密钥泄露的影响面。
• 证书签发：由信任锚点或中间 CA 签发，证书中 Subject 或 SubjectAltName 应与 entityID 一致，避免身份错配。
• 轮换与过渡：密钥轮换时，元数据中应同时发布新旧两把公钥，设置合理的 validFrom 和 validUntil，让对端有窗口期完成切换。例如旧密钥在 2025-06-30 失效，新密钥从 2025-06-01 生效，重叠 30 天。
• 撤销与失效：私钥泄露时，需通过 CRL、OCSP 或元数据更新快速撤销。联邦场景下，元数据更新往往比 CRL 传播更快，因此应优先更新元数据并通知对端。

实体注册与发现：让信任链可扩展

当联邦成员从几个扩展到几十、上百个时，手工交换元数据不再可行。实体注册与发现机制解决“谁在联邦里、如何找到它”的问题。注册环节要求实体提交 entityID、公钥、端点、属性需求等，由注册机构审核后写入注册库；发现环节则允许实体按 entityID 查询元数据，或按属性（如所属机构、服务类型）筛选可用实体。

以某高校联邦为例，注册流程可设计为：

1. SP 管理员在注册门户提交 entityID、ACS 地址、所需属性（如 eduPersonPrincipalName、mail）及签名证书。
2. 联邦运营方验证 entityID 域名归属（如通过 DNS TXT 记录或文件校验），确认 SP 对域名有控制权。
3. 运营方用元数据签名密钥签发该 SP 的元数据，写入聚合元数据文件。
4. IdP 定期拉取聚合元数据，验证签名后加载 SP 公钥与属性需求。
5. 用户访问 SP 时，SP 向 IdP 发起认证请求，IdP 依据元数据中的 ACS 地址和公钥完成断言签名与回传。

发现服务还可提供“身份提供者发现”页面，让用户选择所属机构，或基于邮箱域名自动路由到对应 IdP。对于跨联邦互操作，可采用元数据聚合的“联邦中的联邦”模式：各联邦根互相签名对方的元数据，形成更上层的信任锚点。

信任链构建的检查要点

在实际落地时，可用以下检查表快速核对信任链是否完整：

信任边界的建立不是一次性配置，而是持续运营的过程。元数据会变、密钥会轮换、实体会加入或退出，只有把信任锚点、证书密钥、注册发现三条线协同管理，才能让信任链在动态变化中保持可验证、可撤销、可扩展。