Support for certificate rotation

[deshleman]

SAML IdPs often rotate their signing keys. From my understanding, this is done by publishing two certs to the metadata endpoint in parallel for some period of time to allow service providers to validate against both. This avoids an outage of the service provider when the signing cert is changed.

From what I can tell, this gem does not support publishing two certs in parallel to the metadata endpoint. Is that accurate? Would you take a feature request to make this possible?

[jphenow]

Makes sense - will take a look

[Zogoo]

Let me include some information about this request:

1. Metadata should support multiple certificates
   2.4.1.1 Element KeyDescriptor
   https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
2. We may need to specify the current key info in SAML response
   5.4.5 KeyInfo
   http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Some discussion about multiple certificates.
https://stackoverflow.com/questions/35909251/saml2-metadata-multiple-signing-certificates

@deshlema I hope I could understand correctly your request. Does the above information match your expectation?. If not , please feel free to correct me.

And I have a question about what is your expected action for "SP config". And can you give me some use case of your request.

Lots of modern web services require "manual upload" in Admin page for SP config. And IdP "metadata" will be uploaded only the first time when you configure SP.
In this case, when you revoke IdP certificate how would you like to update the SP config? If you need to upload it again by manually, then does "certificate revoke" feature really needs to have this scenario?. Because, if you do manually upload newly generate metadata with certificate, certificate will just renew in SP side right?

[immerda]

We actually have a patch that I would like to upstream, that supports multiple certificates for a SP. If you are interested I would start to try and somehow extract it in a useful way.

Indeed there are some questions regarding how to rotate, but these are imho orthogonal and should not be handled in this library. E.g. in our case we configure the idp directly through some custom yaml format generated by our config management, not using SP metadata at all. Another option would be to simply periodically pull it.

[carsonwah]

@Zogoo (cc @tngan) I'm having the same issue. Currently I'm using samlify for my SP to login with IdP. Here are my configurations:

idp: {
  signingCert: idpcert,
  encryptCert: idpcert,
}

sp: {
  privateKey: spkey,
  encPrivateKey: spkey,
}

During the rotation period, IdP may provide multiple certs in their metadata. But before switching over, IdP keeps using old key for actual signing/encrypting. At some point, IdP may finally switch and use new key for signing/encrypting. Then existing SP will not work anymore without updating the trusted cert.

So to ensure no down time during cert/key rotation, SP must be able to support multiple IdP certs at the same time.

Seems this feature is supported under metadata configuration: tngan/samlify#364
But for programmatic setup, it is still lacking.

Is it possible to quickly reuse the same logic and support it in programmatic config as well? I would expect target configuration to be like:

Exisiting: {
    signingCert?: string | Buffer;
    encryptCert?: string | Buffer;
}

Target: {
    signingCert?: string | Buffer | string[];
    encryptCert?: string | Buffer | string[];
}

[Zogoo]

@carsonwah I'm sorry for the very delayed answer. Somehow I missed your message.
If I understand correctly you are suggesting that this Gem should support multiple IDP certificates over IDP metadata right? I think the rotation of the IDP certificate should be an IDP service-specific implementation for the SP.
We could add something for the multiple certificates feature.
But the question would be whether the SP is not fully an internal service and somehow polling new metadata automatically via the BE channel, it would not make sense to have multiple certs in the IdP metadata.
Because end the end you have to upload anyway the latest IdP metadata to SP when all certificates are renewed in IdP.