Life cycle management

Enterprise Federation Management

After the initial setup and on-boarding of an organizational federation, there are several common changes and updates that may be needed to an organization's federation setup. Please see the following sections below:

IBMid User Management

IBM will use the email domains provided to give the onboarding organization a list of users in the provided domains that may already exist in the IBMid system. The enterprise must then analyze this list of pre-existing IBMid users and determine how to handle any pre-existing IBMid users. Typically, one of 4 choices will need to be made for each pre-existing user:

Convert: If the pre-existing IBMid is still a valid organizational employee, then typically the organization will want IBM to convert the existing ID so that it will require federated authentication to be used. Open a case at ibm.com/mysupport with Product, "IBMid Enterprise Federation."
Delete: If the pre-existing IBMid no longer matches a valid organizational employee, then IBM can delete the IBMid so that there are no IBMid users impersonating members of the organization that is onboarding.
Leave: Keep the original IBMid as is, as an unfederated IBMid user (the typical example of why this may be requested is to keep a few organizational admins with access to IBMid service in a non-federated fashion, so that they can test/verify that federation is/is not working at some point in time).
Modify: If any of the attributes of the pre-existing users IBMid needs to change (email, name, country, etc) to align with the current organization's values, then the IBMid can be modified to align at the time of on-boarding.

Note: There are IBMids where the "username" does not equal an email address, but the contact email associated with the ID may still match the organizational email domain. In such a case the federating organization may ask IBM to modify the IBMid username to match the email address, so that the ID can be used in a federated fashion. This would come with a potentially negative impact to some IBM cloud apps that use the email address as the identifier for the user - and thus changing the username may affect the access rights of the IBMid.

IBMid User Offboarding

If a federated user leaves an organization that is federated with IBMid, the organization authentication will remain in control of that user. If the user cannot authenticate through their organization's identity provider, they will no longer be able to use their IBMid. If an organization wishes to still remove the user from the IBMid identity system, or if for another business reason the organization needs to have some users off-boarded from federation they can request that an individual user or groups of users that are part of their organizational domain be removed from IBMid by contacting the lifecycle support contact included in support section below.

Attention: The removal of an IBMid user today does not immediately disconnect existing application sessions or invalidate their identity tokens. The length of application sessions will vary by IBM app/service and can be, in some cases, upwards of 14 days. IBMid access tokens can be refreshed, as long as the user's session remains active, for up to 7 days.

Identity provider Management

EF Partner Metadata/Certificate Updates: Some EF Partners may periodically update their metadata containing a certificate with their public key for signature verification. Frequently, partners perform these updates at a coordinated time to minimize downtime. IBMid does not track certificate expiration for EF Partners. When such updates are planned, IBM requests at least a 30 day advance notification so the update can be accommodated within the required change window.

If anything changes on the organization’s identity provider side an update to the SAML partnership may be required. For example, if the signing certificate used by the organization’s identity provider changes, then the organizational admins will need to provide IBM with an updated SAML metadata file by open a request via https://www.ibm.com/mysupport website. The Enterprise Federation (EF) Technical Owner from the organization is required to approve such request.

Similarly, if anything changes on the IBMid (e.g., service provider) side of the SAML partnership, then IBM will provide the organizational admins with a new SAML metadata file for IBMid.

If the organization requests to migrate from one identity provider to another, for example migrating from Ping IdP to Okta IdP, the Enterprise Federation (EF) Business Owner from the organization is required to approve such request.

Federation Decommissioning

If an organization requests to remove its federation relationship with IBMid, they can open a request via https://www.ibm.com/mysupport website. The Enterprise Federation (EF) Business Owner from the organization is required to approve such request. An off-boarding organization will have the choice of removing all IBMids associated with their organization, or converting all these IBMids to non-federated IBMid users.

If converting users to non-federated, it would mean that all the organizational users would be required to go through a 'forgot password flow' on their first time use after federation is removed to generate a local IBMid password/security credential.