Certificates in the SWITCHaai Metadata

Why do we need certificates in metadata?

Certificates embedded or referenced in SAML2 metadata are needed to protect the SAML communication between the Identity and Service Providers. As part of the metadata, it is ensured that the certificates are available at the Identity and Service Providers whenever needed.

What kind of protection do these certificates provide?

On one hand, by signing a SAML assertion, the certificate enables the recipient to properly identify the sender as well as to verify the assertion's integrity. On the other hand, by using the recipient's certificate to encrypt an assertion, the sender ensures that only the intended recipient can access the assertion's content.

What is new with embedding certificates?

Previously, only the certificates of the accepted Root CAs (SwissSign, Cybertrust, Verisign, etc.) were directly embedded in SAML2 metadata. For Identity and Service Providers, only the common name of the certificate was referenced, but the certificate itself was not embedded.
This allowed the identity and service providers to identify the sender and to check the assertion's integrity, but it was however impossible to encrypt an assertion because the key of the recipient was not available to the sender.

In addition, when a certificate is directly embedded, it is not necessary to have its issuing certificates at hand when verifying a signature. Therefore, there is no need to append the intermediate/issuing certificates chain anymore. One can directly trust the embedded certificate, since its issuing certificate was checked by a well-defined process [1] when accepting a certificate to be embedded into the SAML2 metadata.

So, once all the certificates of Identity and Service Providers are embedded, the certificates of the accepted Root CAs can then be removed from metadata.


[1] Process to Manage Embedded Certificates for the Federation Metadata

SWITCHaai Certificate Requirements