...
SAML Certificates in Federation Metadata
This article discusses the use of X.509 certificates in Federation metadata. It has security implications so please read it carefully.
...
The InCommon Federation is based on the Explicit Key Trust Model, one of several possible metadata trust models. Consequently, the use of long-lived, self-signed certificates in metadata is strongly recommended. Certificates signed by a Certification Authority (CA) are allowed, and in most situations will work just fine, but the use of certificates other than self-signed certificates is discouraged. See the Background information and the Interoperability notes below for further discussion.
...
Any certificates you want to use with your SAML software are uploaded via the Federation Manager. Typically only one certificate is required per entity but multiple certificates may be uploaded and used as needed. In particular, multiple certificates may be used to facilitate the controlled rollover of expired certificates or compromised keys. To avoid interoperability problems, refer to the Certificate Migration topic for recommended guidelines regarding the rollover process.
...
| Tip | ||
|---|---|---|
| ||
Before generating a new private signing key for your IdP, read the IdP Key Handling topic. |
Contents
| Table of Contents | ||
|---|---|---|
|
Background
In the base SAML metadata specification [1], a certificate signing authority (CA) has no assumed relevance to the trust model that secures the interactions among a federation's participants. In fact, certificates signed by a CA are discouraged since they can create interoperability issues in certain situations and lead to configurations that mistakenly establish trust based on the certificate signer. Allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not registered in the Federation.
...