Enable automatic SAML federation metadata refresh for IBMid integrations

Idea description

Currently, when the token-signing certificate of a federated Identity Provider is approaching expiration or being renewed, the customer must open a support ticket with IBM and request a manual metadata update on the IBMid side.

This manual process creates an operational dependency on IBM Support and requires careful coordination between the customer and IBM to ensure that the updated signing certificate is imported before the existing certificate expires. It also introduces administrative effort for both parties.

Modern SAML federation solutions commonly support automatic retrieval and periodic refresh of federation metadata from a configured metadata URL. The metadata can contain both the current and the next token-signing certificate, allowing the service provider to establish trust with the new certificate before the Identity Provider begins using it.

We propose that IBMid implement support for automatic federation metadata retrieval and refresh. IBMid would periodically retrieve, validate, and process updated federation metadata published on the customer's end. IBMid should recognize newly published token-signing certificates while retaining existing valid certificates during the rollover period.

Automatic metadata refresh is important because it would:

• Reduce the risk of authentication outages during certificate rollover.
• Eliminate the need to open an IBM Support ticket for every signing-certificate renewal.
• Reduce manual coordination and administrative effort for customers and IBM Support.
• Allow customers to follow shorter and more secure certificate lifecycles.
• Improve alignment with modern SAML federation and certificate rollover practices.
• Support planned and emergency certificate rotation more effectively.

Business impact

Without automatic metadata refresh, every token-signing certificate renewal becomes a time-sensitive manual activity. If the metadata update is delayed, missed, or incorrectly coordinated, IBMid may no longer trust assertions signed with the new certificate. This could prevent all federated users of the affected organization from signing in.

The risk becomes greater as the industry moves toward shorter certificate lifecycles and automated certificate management. For example, CA/Browser Forum Ballot SC-081v3 reduces the maximum validity of publicly trusted TLS certificates to 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029. Although these requirements seemingly do not directly apply to token-signing certificates at this time, they demonstrate the broader direction of certificate management practices. Organizations may consequently introduce shorter validity periods for token signing certificates through their own security policies. Without automated metadata refresh, this would mean more frequent rotations, additional IBM Support tickets, greater operational workload, and a higher probability of authentication disruption caused by delayed or unsuccessful rollover.

Requested functionality

We request that IBMid provide the following capabilities:

1. Retrieve customer published metadata automatically at a configurable or IBM-defined secure interval. Metadata must be retrieved only from a predefined HTTPS URL.
2. Validate the metadata source and reject invalid, untrusted, or malformed metadata.
3. Detect and import newly published token-signing certificates automatically.
4. Support overlapping current and future signing certificates during a rollover period.
5. Retain the previous certificate for an appropriate transition period to avoid authentication interruptions.
6. Provide notifications or audit records when metadata or trusted signing certificates change.
7. Provide an administrative option to trigger an immediate metadata refresh.
8. Preserve a documented manual update procedure for exceptional or emergency cases.

Expected outcome

Implementing this capability would make IBMid federation integrations more resilient, and operationally efficient. It would reduce outage risk, remove unnecessary support dependencies, and allow customers to rotate token-signing certificates according to appropriate security policies without introducing repeated manual work.