...
This keypair ideally never changes outside of a catastrophic event. If your policies require you to change it, you should budget a large amount of time from the IdP operations team and all of your affected customers to coordinate the change, or you will need to accept a significant amount of service disruption. Some disruption is also unavoidable in most deployments even if you do everything correctly.
| Tip |
|---|
Make sure you don't back up this key as part of general server backup. If you do, you will essentially give all of your backup operations staff the ability to compromise your organization through impersonation attacks with the key and that won't sit well with your auditors. If you want to avoid frequent demands to change the key, don't back it up "normally". Use a dedicated strategy to archive the key safely and limit access to a small number of authorized staff. |
Back-Channel TLS Key and Certificate
...
A second key pair essential to the security of the IdP is the private key and certificate used to enable TLS on the back channel, discussed extensively above. Depending on the SAML options used, compromise of this key can could also lead to total compromise of the IdP.
The deployment of this key and certificate involves your web server, rather than the IdP application, so actual configuration of this key is outside the scope of this documentation. And of course if you don't need to support the back channel, then you can ignore this key pair.
...
This keypair ideally never changes outside of a catastrophic event. The advice above for the signing key applies.
Encryption Key and Certificate
...
- Signing SAML requests (or, in a few cases such as Single Logout, SAML responses)
- Client or server authentication of back-channel SAML requests or responses (SOAP primarily)
Signing-only certificates are communicated via a <md:KeyDescriptor use="signing"> element in SP metadata. When configured in the usual fashion, the IdP will completely ignore the content of the certificate other than the public key, but in a back-channel scenario the web server may or may not ignore the certificate's content depending on the software and configuration involved (discussed above).
...
Most, though not all, SPs have an encryption key pair. This is the analog of the IdP's encryption key pair above; the public key is used by the IdP to encrypt data while the SP uses its private key to decrypt it.
Encryption-only certificates are communicated via a <md:KeyDescriptor use="encryption"> element in SP metadata. The IdP, when configured in the usual fashion, will completely ignore the content of the certificate other than the public key.
...