Digital signing policy coordination
To coordinate digital signature policy, partners must first agree about whether they will sign SAML messages or tokens.
In some cases, such as SAML security token service (STS) tokens and single sign-on (SSO) assertions sent across the POST binding, the protocol specifications require signatures. The PingFederate administrative console and the runtime protocol engine enforce these requirements. Some partner connections specify other, optional uses of the digital signatures between partners.
If a trusted, self-signed certificate authority (CA) does not issue a digital-signing certificate, then the signing partner must send the public-key certificate out-of-band, such as through email, to the partner. The partner must import the certificate into PingFederate when configuring a connection to the signing partner for SSO, single log-out (SLO), or STS.
If a trusted CA signs the certificate and the signing partner chooses to embed the certificate in all signed messages, then the verifying partner uses the embedded certificate for signature verification, after validating it against the Subject Distinguished Name (DN) of the original certificate. Because validation only requires the Subject DN, the public-key certificate might not be sent out-of-band.
|
During the signature verification configuration, PingFederate extracts the Subject DN from the certificate when available. |
The next section provides more information about the two alternative signature-verification trust models described above from the standpoint of the verifying partner.
Trust models
For validating digital signatures, PingFederate provides a selection of trust models in the administrative console for each partner connection, based on the certificate categories listed below. For each trust model, PingFederate always verifies the currency of the certificate and the validity of the message in the certificate specified. Additional checks depend upon the trust model selected.
- Anchored certificate
-
In this case, certificates used for signature verification must be issued by a trusted CA, and the certificate chain must be verifiable recursively back to the root issuer. PingFederate validates the certificate, including recursive revocation checking (when enabled) back to the issuer,for all signed messages from the partner. By default, PingFederate also prompts for the Issuer DN of the certificates to mitigate potential man-in-the-middle attacks and to provide a means to isolate certificates used by different connections.
In addition, when choosing the anchored trust model, the incoming message must include the verification certificate for the signature. PingFederate uses that certificate to verify signatures from the partner if its Subject DN matches the partner’s public certificate (as specified in the administrative console), the Issuer DN (if specified) matches one of the issuers in the chain, and the Issuer CA certificate is part of the trusted store. This feature provides a dynamic trust model that overcomes the problem of interrupting service to change out expired certificates.
- Unanchored Certificate
-
In the unanchored certificate model, incoming signature verification exclusively uses the certificates imported for a connection into PingFederate or a secondary, backup certificate, either self-signed or trusted CA-issued, when specified. This verification does not apply to the certificate chain. However, when enabled, existing chains receive revocation checking as far as available.