Asynchronous renewal of the public key in the signing certificate

In SAML, communication between the Identity Provider (IDP) and Service Providers (SPs) is cryptographically secured. Each IDP and SP stores its signing key pair in its key store, while the public keys (wrapped in X.509 certificates) are included in the metadata files idp.xml and sp.xml.

Both the IDP and the SPs must sometimes renew their public keys. This may be the case if the key gets compromised or if it will be replaced by a longer, more secure key. IAM supports multiple signing certificates in a single metadata file, allowing old and new keys to coexist. This makes it possible to rotate the signing keys asynchronously, without requiring all parties to switch at the same time.

This article explains how to renew the public key in the signing certificate asynchronously. It first covers renewal by the IDP, then by the SP. In both cases, IAM may act either as IDP or SP.

Notice

This article is about renewing the public key. In the context of this article, expiration of the certificate itself is irrelevant. The certificate only serves as a wrapping of the public key.

Also, the described procedure only works for key renewal in a signing certificate.

The IDP renews the public key in the signing certificate

The next table shows the steps required from both the IDP and SPs when the IDP renews the public key in the signing certificate.

Step	Performed by the IDP	Performed by the SP
1	The IDP creates a new signing key pair and stores it in its key store. For more information, see Key store files.
2	The IDP adds the new public signing key in the form of an X.509 certificate to the `idp.xml` metadata file (`ds:X509Certificate` tag). For more information, see IDP metadata file (idp.xml).
3	The IDP shares the new signing certificate with the respective SPs. There are two options: The IDP shares the updated `idp.xml` file, which contains both the current and the new certificate. The IDP only shares the new certificate.
4		Each SP either adds the new signing certificate to the existing `idp.xml` metadata file (`ds:X509Certificate` tag), or it replaces the existing `idp.xml` file entirely. For more information, see IDP metadata file (idp.xml). If IAM acts as SP, this change requires a restart of the IAM instance.
5	The IDP informs the SPs in time about the IDP's certificate renewal date.
5		The SPs do not have to switch at the same time, as the old and new certificate can coexist in the updated `idp.xml` file during the transition period.
6	On rollover date, the IDP adjusts the `signingCertAlias` attribute in the `idp-extended.xml` file, such that it points to the new signing key pair in the key store. For more information, see IDP extended metadata file (idp-extended.xml). If IAM acts as IDP, this change requires a restart of the IAM instance.
7	After rollover, the IDP should Remove the old signing certificate from the `idp.xml` file and share the updated file with the SPs. Remove the old keys from the key store. If IAM acts as IDP, this change requires a restart of the IAM instance.
7		After rollover, each SP should Either remove the old signing certificate from the `idp.xml` file, or replace the current `idp.xml` file entirely with the updated `idp.xml` file shared by the IDP. If IAM acts as SP, this change requires a restart of the IAM instance.

The SP renews the public key in the signing certificate

The next table shows the steps required from IDP and SP when an SP renews the public key in the signing certificate.

Step	Performed by the IDP	Performed by the SP
1		The SP creates a new signing key pair and stores it in its key store.
2		The SP adds the new public signing key in the form of an X.509 certificate to the `sp.xml` metadata file (`ds:X509Certificate` tag). For more information, see SP metadata file (sp.xml)
3		The SP shares the new signing certificate with the respective IDP. There are two options: The SP shares the updated `sp.xml` file, which contains both the current and the new certificate. The SP only shares the new certificate file.
4	The IDP either adds the new signing certificate to the existing `sp.xml` metadata file (`ds:X509Certificate` tag), or it replaces the existing `sp.xml` file entirely. For more information, see SP metadata file (sp.xml). If IAM acts as IDP, this change requires a restart of the IAM instance.
5		The SP informs the IDP in time about the SP's certificate renewal date.
5	The IDP does not have to switch at the same time, as the old and new certificate can coexist in the updated `sp.xml` file during the transition period.
6		On rollover date, the SP adjusts the `signingCertAlias` attribute in the `sp-extended.xml` file, such that it points to the new signing key pair in the key store. For more information, see SP extended metadata file (sp-extended.xml). If IAM acts as SP, this change requires a restart of the IAM instance.
7		After rollover, the SP should Remove the old signing certificate from the `sp.xml` file and share the updated file with the respective IDP. Remove the old keys from the key store. If IAM acts as SP, this change requires a restart of the IAM instance.
7	After rollover, the IDP should Either remove the old signing certificate from the `sp.xml` file, or replace the current `sp.xml` file entirely with the updated `sp.xml` file shared by the SP. If IAM acts as IDP, this change requires a restart of the IAM instance.