Page History

...

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.

It is easy to create a self-signed certificate with the OpenSSL command-line tool. Before you do this, however, take a moment to consider how best to handle the all-important private key. The Key Handling topic shows how to create a self-signed certificate and how to maintain the security of the corresponding private key

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.unmigrated-wiki-markup

InCommon conforms to the _SAML V2the SAML V2.0 Metadata Interoperability Profile_ \ [2\] from OASIS. Participant site administrators securely transmit X.509 certificates and metadata to InCommon via the administrative web interface. InCommon signs the entire metadata file, securing the keys of its participants whether those keys are bound to self-signed certificates or certificates signed by a CA. The critical element in the certificate is the public key, which is associated with an entity via its entity ID. Theoretically, if all the relevant software systems could accept a public key without a certificate wrapper, InCommon would only need to include the public key of each entity. As it is, the certificate is a convenient container for the public key, the critical element being that the key is bound to a particular entity in the metadata.

Requirements

InCommon sets the following security and trust requirements around certificates included in Federation metadata:

...

• A potential federation partner (especially a partner not using the Shibboleth software) may question the use of self-signed certificates. As discussed in the Background section, there are, in fact, fewer interoperability issues with self-signed certificates compared to CA-signed certificates.unmigrated-wiki-markup
• The Shibboleth software does not check the expiration dates of certificates \ [4\], but *expired certificates often cause interoperability issues* with other software (such as AD FS 2AD FS 2.0 and the OIOSAML Java SP) and with older versions of Apache used to deploy the Shibboleth IdP. InCommon recommends that you plan ahead and [migrate to an unexpired certificate|Certificate Migration] well ahead of your certificate's expiration date.
• For key management purposes, InCommon allows multiple certificates per role descriptor at any time. (You can log into the administrative interface, select a particular role, and associate more than one certificate with that role for the purposes of migrating from one certificate to another.) Bear in mind, however, that some SAML implementations do not support multiple keys properly and you may want to test this capability with your non-Shibboleth partners. For example:
  • EZProxy is known to ignore additional keys beyond the first.
  • AD FS 2.0 will not consume an <md:EntityDescriptor> element containing more than one encryption key.
• At the deployer's convenience, a single certificate may be bound to multiple SPs in InCommon metadata. However, some implementations (e.g., AD FS 2.0) do not allow the same certificate to be used by two distinct entities.
• If the certificate will be used for TLS server authentication, the certificate's CN (and/or subjectAltName) value should match the server's hostname. This is especially true for IdPs but may also be true in certain advanced scenarios where the SP acts as a SOAP responder.
• Avoid certificates with special certificate extensions, since some implementations will actually try to use them. For example, AD FS 2.0 will attempt to access the CRL at the location given in the CRL Distribution Point certificate extension.

References

...

\[1\] _Metadata for the OASIS Security Assertion Markup Language (SAML) V2 V2.0_ [http://saml.xml.org/saml-specifications] \
[2\] _SAML V2] SAML V2.0 Metadata Interoperability Profile_ [http://wiki.oasis-open.org/security/SAML2MetadataIOP] \
[3\] [X.509 Certificates in the Federation Metadata|http://internet2.na6.acrobat.com/p46467886/]: A technical webinar presented by the _InCommon Technical Advisory Committee_ (October 22, 2009) \[4\] _The Shibboleth ExplicitKey Trust Engine_ [ (October 22, 2009)
[4] The Shibboleth ExplicitKey Trust Engine https://wiki.shibboleth.net/confluence/display/SHIB2/ExplicitKeyTrustEngine
]5] Shibboleth Security and Networking https://wiki.shibboleth.net/confluence/x/VoEOAQ