In the past few weeks, we were told we had to update all of our SAML certificates. What this entails is going into the self help portal we have and switching over the certificate that the SAML connection uses. This has to be done while you are logged into the target gateway otherwise you become locked out.
Then, once the certificate has been switched, the new metadata is imported via URL. Through this tough we have noticed some undesirable behavior as follows:
Even if the new metadata imports, the save button does not become active.
The work around was to click come unrelated checkbox like “Force Authn *” on and then off again. Once that was done the option to save the new metadata became available.
We would like to request that this process be changed to help prevent errors because SAML certificates have to be updated at least once per year so this will be a recurring theme:
Whenever the metadata has been updated, that alone should trigger that the save button become active
If the user imports new metadata but then tries to navigate away from the SAML IDP settings page without saving, they should be alerted that there are unsaved changes.
This is really important because if you mess up here, you are locked out everywhere.
Separate but related topic, we need a way to push new SAML metadata through EAM (I have a seperate post in feature requests).
This can be alleviated by following good cert rotation practices. For example: Let's say you have one cert installed at the IdP (cert A). After a few months, you would like to rotate to a new cert (cert B). Typically, you will want to install B so that it shows up as a second cert in the IdP's metadata, yet A will still be the cert used for signing SAML responses/assertions. After installing cert B, export and circulate the new IdP metadata which contains both certs to each SP so that they all know to trust SAML responses signed using either A or B. Once all SPs are aware of the new cert, you can safely uninstall cert A from the IdP, and optionally export and re-circulate IdP metadata containing only cert B. This should result in zero downtime.
When you import the new IdP metadata, does it actually change any of the settings on the Ignition IdP config? If not, then the configuration state in the UI is not considered "dirty", which means the Save button will not be enabled, because nothing has technically changed.
I just tried importing metadata which does change the configuration settings in the config UI, and I do see the Save button light up.
I agree - in fact, we already have an internal ticket logged for this capability, so I'll go ahead and link this thread to that ticket.
@jspecht in the portal that we use, we can see multiple AVAILABLE certs on a IDP connection (ex: a new one, and one that will expire) but we have no way to assign both of them to a single metadata url, we can only use one at a time. So assuming we are updating the metadata on an existing IDP connection in the gateway, we can either see the new cert or the old cert, but not both.
To fully confirm, when importing new metadata to an existing IDP in the gateway, we can clearly see the actual cert values change on the screen, but the save button did not illuminate. If we clicked one of the boolean fields true then false again, that seemed to force a refresh after which the save button illuminated.
Seems like an unfortunate limitation in whatever IdP you are using
How about this: can you create two "IdP connections" - A and B
At first, enable A and disable B. Distribute A's metadata to each Gateway to start with, then when you need a new cert, install it on B, enable B (while leaving A enabled), then distribute B's metadata to each Gateway and when that is done, disable A. Rinse and repeat each time you need to rotate certs.
Which version of Ignition are you running when you hit this issue? And are you importing by URL or importing by file?
Is it possible that you can DM me two things (since I am unable to reproduce the issue on my end):
The export of the IdP configuration in Ignition before you update with the new metadata
The IdP metadata XML file that you want to import to update the IdP configuration in Ignition
I understand, that is frustrating. Your EAM push idea is a good one. Another idea that comes to mind is if we add support for periodically reloading IdP metadata by URL and automatically update settings based on the new metadata. We have a similar capability already for OIDC IdPs.
At first, enable A and disable B. Distribute A’s metadata to each Gateway to start with, then when you need a new cert, install it on B, enable B (while leaving A enabled), then distribute B’s metadata to each Gateway and when that is done, disable A. Rinse and repeat each time you need to rotate certs.
This is exactly what we have planned. Based off of feature 2155, no matter how many gateways, we just add additional ACS URL's to the connection. We then always maintain 2 connections: one in use and one to be used next.
Just to be certain, I upgraded this particular machine from 8.1.0 to 8.1.10 and I cannot get the save button to show up correctly. I am importing via URL. I have DM'd you the requested info.
Yeah, for EAM the functionality looks like this:
Using feature 2155, the entire fleet uses 2 certs in rotation with a unified entity ID and ACS URL's = to all the gateway addresses (can be several hundred)
When it comes time to update, given a functional network connection, we specify the new metadata in EAM and everything gets upgraded. The metadata switch over time itself is 5 minutes so exactly how the change over would occur would be a topic to discuss.
The latest early access build (8.1.12-b20211025) contains a fix for the issue where the save button is disabled when importing new SAML metadata on the SAML IdP config page: Nightly 8.1 Changelogs - 2021 - #177 by sreis
Tomorrow’s early access build should contain a new opt-in feature to SAML IdPs for automatically reloading the latest trusted signature verifying certificates and keys from the IdP’s metadata XML URL as soon as an authentication response signed using an unknown certificate or key is encountered.
When the IdP Metadata URL is set and the “Use IdP Metadata URL” checkbox is enabled in the red box in the screen shot above, Ignition will always source its set of signature verifying keys and certificates from the IdP’s metadata XML endpoint (keys and certs configured on the IdP’s settings will not be used). See below sequence diagram for how this works.
