IdP certificate rotation

[augustuswm]

Currently we do not have support for handling certificate rotations (both for certificates issued by the IdP and the SP).

The current plan is to support a create + delete rotation mechanism so that operators can create a new IdP configuration, perform testing to confirm it works, and then deleting the old configuration. There are a few pieces missing to be able to support this:

1. Add support for deleting an IdP configuration.
2. The name of the IdP configuration is a unique value that is used in multiple places
   • ACS Url, login elements for the silo users (urls and UI elements)
   • As a result (assuming delete was implemented) this means that certificate rotation is an outward visible change to silo users
   • Ideally to a silo user there would be no visible effect of a certificate rotation
3. If multiple IdP configurations are allowed to have the same ACS Url, how do we decide which to pick.

Part of this exercise should be mapping out the steps that we expect an operator to take when rotating certificates. I'll work on putting together some examples based on the IdPs we currently support.

[augustuswm]

Silo IdP configurations are annotated as SP-X
IdP configurations (sometimes name applications) are annotated IdP-X

In all examples it is assuming there is a valid configuration pair already setup on the silo (SP-A, IdP-A)

IdP certificate rotation

Google Workspace (5 year cert)

1. Create new key + cert in Google Workspace
2. Create new application IdP-B in Google Workspace
3. Create new IdP configuration SP-B in silo with metadata from IdP-B
4. Update IdP-B with parameters from SP-B
5. Test that login via SP-B works
6. Update IdP-A to use new certificate and parameters from SP-B
7. Delete SP-A
8. Delete IdP-B

Keycloak (10 year cert)

1. Create new key in Keycloak
2. Create a new client IdP-B in Keycloak
3. Create new IdP configuration SP-B in silo with metadata from IdP-B
4. Update IdP-B with parameters from SP-B
5. Disable old key in Keycloak and test that login via SP-B works. Note that while the old key is disabled, users will not be able to log in via SP-A. This is a limitation in Keycloak as it does not permit selecting a signing key per client.
6. Update IdP-A to use parameters from SP-B
7. Delete SP-A
8. Delete IdP-B

Duo (13?? year cert)
I have not yet found an option for manually rotating a signing key. Assumption may be that users are able to update their IdP metadata as new certificates are added. Notably the certificate we are given is valid for ~13 years (expires 01/2038).

Okta (10 year cert)

1. Create new application IdP-B in Okta
2. Create new IdP configuration SP-B in silo with metadata from IdP-B
3. Update IdP-B with parameters from SP-B
4. Test that login via SP-B works
5. Delete SP-A (Certificates are bound to applications so we can not port the known working settings from IdP-B)
6. Delete IdP-A

Very similar flows would be needed for handling expired SP certificates. After walking through these four, all seem to operate under the assumption that the SP can update it's IdP metadata in place to accept new certificates. I still think we should consider allow updates to ease the process for operators and allow us to avoid trying to solve points #2 and #3 above. I'm not sure that the create + delete method provides more protection from lockout than a create + update in place does. While it would be more work, implementing something like revision control over IdP configuration settings would provide both in place updates and allow for options around rollback.

[augustuswm]

Another alternative would be to not allow mutations create/update/delete against the silo you are currently authenticated against. This ensures that the user always has a working silo.

[davepacheco]

CC @askfongjojo @morlandi7 we probably need to talk about prioritizing this, maybe at the product roundtable.

[augustuswm]

@davepacheco @jmpesp What are the current concerns around allowing updates to an IdP configuration (specifically for the case where the logical IdP is not changing)? I know there is the lockout issue, but are there others that we can enumerate?

As noted above, creating a new IdP configuration can lead to a new connection on the IdP side which may require a new "application" or "client" on the IdP side. This is fine for testing, but there is definite friction there, and may lead to visible differences to the silo end user.

It seems like we can work around the lockout issue with create + test + update vs create + test + delete, or preventing changes to the IdP of the current user's silo (which is the safer of the two). But I'm not sure if there are other issues?

[augustuswm]

Confirmed that at least in the case of Google, when a certificate expires Google will refuse the authentication request with a "Malformed Certificate" 400 error and displays the encoded form of the expired certificate in the browser. In the Google admin the SAML app has no certificate listed and the expired certificate is no longer an option that can be selected.