Add sp_cert_multi to facilitate SP cert/key rotation #673
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #560
This PR introduces
sp_cert_multi
parameter which is analogous toidp_cert_multi
. It allows developers to have fine-grained control over SP certs and private keys, including:The changes are summarized as follows:
Add
SamlSettings sp_cert_multi
parameter. It has the following shape:(Note: You can use same certs for signing/encryption, and same PK everywhere. It's completely backward compatible with current functionality.)
sp_cert_multi
is mutually exclusive with the following:certificate, certificate_new, private_key
.If
security[:check_sp_cert_expiry]
is true, Ruby Saml automatically uses the first non-expired certificate insp_cert_multi[:signing]
for signing, and only uses private keys associated with non-expired certs insp_cert_multi[:encryption]
for decryption. This is evaluated in realtime, so as soon as your old cert expires your app automatically starts signing with the new one.The validation error
:check_sp_cert_expiration
is now raised only if ALL SP certs are expired. This is a slight behavior change;Settings.certificate
was expired butSettings.certificate_new
was not, an error would be raised.certificate_new
for signing. (This case was not previously in the tests, but I've now added a test for it with the new logic.):check_sp_cert_expiration
now also validates the certificatenot_before
condition; previously it was only validatingnot_after
.If
:check_sp_cert_expiration
is true, we now no longer include expired certs in the generated SP metadata. This is a good practice because having expired certs may cause the IdP system to throw an error, depending on how strictly it does its validation.Refactor so that internal references to
get_sp_cert
,get_sp_private_key
, etc. now point to the new structure of multiple certs.When performing decryption, we now try all private keys under
sp_cert_multi[:encryption]
(this is analogous to how we try all IDP certs inidp_cert_multi[:signing]
when verifiying the IDP signature.)Extract out
OneLogin::RubySaml::Utils.build_cert_object
andbuild_private_key_object
.Deprecate the
certificate_new
parameter sincesp_cert_multi
fulfills the same role better. It still works but it is removed from the docs.When there are multiple SP certs, the ordering of SP KeyDescriptor node in the SP metadata XML will now be all signing keys first, and then all encryption keys. (Previously it would be signing, encryption, signing, encryption.) This does not affect XML integrity in any way.
This PR contains unit tests and integration tests for all major SP signing flows (both Redirect and POST). Decryption is covered as well.