跳到主要内容

7. 示例使用场景 (Example Usage Scenarios)

本节中的示例不具有规范性, 用于说明第 5.2 节和第 5.3 节中描述的流程.

以下示例描述部署了 MATF 的 "Skolfederation" federation 内的一个场景. 客户端和服务器都是该 federation 的注册成员. 在此场景中, 客户端使用 SS 12000:2018 管理跨域用户账户, 该标准是 System for Cross-domain Identity Management (SCIM) 扩展.

   +------------------------------------------------------+
   |                                                      |
   |                  Federation Metadata                 |
   |                                                      |
   +-----+-------------------------------+----------------+
         |                               |
        (A)                             (A)
         |                               |
         v                               v
   +-----------+         +--------------------------------+
   | Local MD  |         |            Local MD            |
   +-----+-----+         +------+---------------------+---+
         |                      |                     |
        (B)                    (C)                   (F)
         |                      |                     |
         v                      v                     v
   +-----------+         +--------------+         +-------+
   |           |         |              |         |       |
   |  Client   +---(D)-->+ Intermediary +---(E)-->+  App  |
   |           |         |              |         |       |
   +-----------+         +--------------+         +-------+

A. 客户端和服务器按第 4.2 节所述检索 federation metadata 并更新其 local metadata store.

B. 客户端根据 metadata claim 选择服务器端点, 并预加载为该端点发布的 pins.

C. 如果执行 certificate chain validation, TLS 客户端或 intermediary 使用 federation metadata 中为所选实体列出的 issuers 配置其 trust store.

D. 客户端发起到所选 base_uri 的 TLS 连接, 并出示其 client certificate.

E. 如果 intermediary 终止 TLS 会话, 它会按第 5.3 节和第 5.6 节所述, 将从 TLS 会话派生的 identity material 转发给 application.

F. application 将派生 pin 映射到匹配的 metadata 条目, 并使用关联的 entity_id 进行标识和授权.

7.1. 客户端行为 (Client Behavior)​

为客户端颁发一个 certificate. 客户端的 certificate issuer 和 public key pins 发布在 federation metadata 中.

当客户端发起到远程服务器 (由服务器的 entity_id 标识) 的连接时, 执行以下步骤:

  1. 客户端从已标识实体的 servers 列表中选择一个服务器端点, 其 tags 与所需服务能力匹配.

  2. 客户端从其 local metadata store 预加载所选端点的 pins. 如果执行 certificate chain validation, 客户端还会加载为该实体列出的 issuers.

  3. 客户端使用 base_uri 发起到所选端点的 TLS 连接, 并出示其 client certificate.

  4. 客户端按第 5.3 节所述对服务器 certificate 执行 pin validation. 该验证可以由 TLS stack 在 handshake 期间执行, 也可以由 application logic 在连接建立后执行, 但必须在交换任何 application data 之前完成.

  5. 如果验证成功, 客户端继续执行 application transaction.

7.2. 服务器行为 (Server Behavior)​

为了接受来自客户端的入站连接, 服务器使用 federation metadata 对所出示 client certificate 中的 public key 执行 pin validation. federation metadata 会发布客户端 public key pins, 对于执行 certificate chain validation 的部署, 还会发布允许的 issuers.

当服务器收到来自远程客户端的 TLS 连接尝试时, 执行以下步骤:

  1. 服务器被配置为请求或要求 client certificate. 如果执行 certificate chain validation, 则使用 federation metadata 中发布的 issuers 填充 trust store. 否则, 服务器请求 client certificate 而不执行 issuer validation (例如 optional_no_ca).

  2. 服务器可以预先筛选 federation metadata, 以识别其愿意通信的客户端集合, 并按第 5.2 节所述仅预加载这些客户端的 pins.

  3. TLS handshake 完成后, 服务器从所出示 certificate 派生客户端的 pin, 并将其与预加载的 pins 匹配. 找到匹配项后, 服务器从相应 metadata 条目确定客户端的 entity_id.

  4. 如果 pin validation 成功, 服务器继续执行 application transaction. 如果 pin validation 失败, 服务器终止连接.

7.3. SPKI 生成 (SPKI Generation)​

以下示例展示如何使用 OpenSSL 从 PEM 编码 certificate 生成 SPKI fingerprint.

  openssl x509 -in <certificate.pem> -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  openssl enc -base64

7.4. Curl 和公钥固定 (Curl and Public Key Pinning)​

以下是使用 curl 进行 public key pinning 的示例.

  curl --cert client.pem --key client.key \
  --pinnedpubkey \
  'sha256//0Ok2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' \
  https://host.example.com
最后于 更新