7. Example Usage Scenarios
この節では MATF の RFC 原文を保持し, federation trust model, metadata repository, public key pinning, JSON/JWS metadata, usage scenarios, deployments, security considerations, JSON Schema を含めます.
7. Example Usage Scenarios
The examples in this section are not normative and illustrate the
procedures described in Sections 5.2 and 5.3.
The following example describes a scenario within the federation
"Skolfederation" where MATF is deployed. Both clients and servers
are registered members of the federation. In this scenario, clients
manage cross-domain user accounts using SS 12000:2018, which is a
System for Cross-domain Identity Management (SCIM) extension.
+------------------------------------------------------+
| |
| Federation Metadata |
| |
+-----+-------------------------------+----------------+
| |
(A) (A)
| |
v v
+-----------+ +--------------------------------+
| Local MD | | Local MD |
+-----+-----+ +------+---------------------+---+
| | |
(B) (C) (F)
| | |
v v v
+-----------+ +--------------+ +-------+
| | | | | |
| Client +---(D)-->+ Intermediary +---(E)-->+ App |
| | | | | |
+-----------+ +--------------+ +-------+
A. Clients and servers retrieve federation metadata and update their
local metadata stores as described in Section 4.2.
B. The client selects a server endpoint based on metadata claims and
preloads the pins published for that endpoint.
C. If certificate chain validation is performed, the TLS client or
intermediary configures its trust store using the issuers listed
in the federation metadata for the selected entity.
D. The client initiates a TLS connection to the selected base_uri
and presents its client certificate.
E. If an intermediary terminates the TLS session, it forwards
identity material derived from the TLS session to the application
as described in Sections 5.3 and 5.6.
F. The application maps the derived pin to a matching metadata entry
and uses the associated entity_id for identification and
authorization.
7.1. Client Behavior
A certificate is issued for the client. The client's certificate
issuer and public key pins are published in the federation metadata.
When a client initiates a connection to a remote server (identified
by the server's entity_id), the following steps are performed:
1. The client selects a server endpoint from the identified entity's
servers list whose tags match the required service capabilities.
2. The client preloads the selected endpoint's pins from its local
metadata store. If certificate chain validation is performed,
the client also loads the issuers listed for the entity.
3. The client initiates a TLS connection to the selected endpoint
using the base_uri and presents its client certificate.
4. The client performs pin validation for the server certificate as
described in Section 5.3. This validation may be performed by
the TLS stack during the handshake or by application logic after
the connection is established, but it completes before any
application data is exchanged.
5. If validation succeeds, the client proceeds with application
transactions.
7.2. Server Behavior
To accept inbound connections from a client, the server uses
federation metadata to perform pin validation of the public key in
the presented client certificate. The federation metadata publishes
client public key pins, and for deployments that perform certificate
chain validation, the allowed issuers.
When the server receives a TLS connection attempt from a remote
client, the following steps are performed:
1. The server is configured to request or require a client
certificate. If certificate chain validation is performed, the
trust store is populated using the issuers published in the
federation metadata. Otherwise, the server requests a client
certificate without issuer validation (for example,
optional_no_ca).
2. The server can prefilter the federation metadata to identify the
set of clients it is willing to communicate with and preload only
the pins for those clients, as described in Section 5.2.
3. After the TLS handshake completes, the server derives the
client's pin from the presented certificate and matches it
against the preloaded pins. When a match is found, the server
determines the client's entity_id from the corresponding metadata
entry.
4. If pin validation succeeds, the server proceeds with application
transactions. If pin validation fails, the server terminates the
connection.
7.3. SPKI Generation
The following is an example of how to use OpenSSL to generate a SPKI
fingerprint from a PEM-encoded certificate.
openssl x509 -in <certificate.pem> -pubkey -noout | \
openssl pkey -pubin -outform der | \
openssl dgst -sha256 -binary | \
openssl enc -base64
7.4. Curl and Public Key Pinning
The following is an example of public key pinning with curl.
curl --cert client.pem --key client.key \
--pinnedpubkey \
'sha256//0Ok2aNfcrCNDMhC2uXIdxBFOvMfEVtzlNVUT5pur0Dk=' \
https://host.example.com