Information required

Email domains to be associated with federation

Organizations adopting IBMid Enterprise Federation must provide a list of all email domains which organizational users may use to login to IBMid.

Changes (as needed) to pre-existing IBMid users

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 older 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.

Organization name to be displayed to user during authentication

The IBMid interface, when seeing a federated user, informs the user that they are going to be sent to their organization to authenticate. Organizations must give IBM a name that is used to display to the user, which must be limited to 30 characters.

The name that will be used must be supplied in the IdP SAML metadata provided by the federating organization to IBM, within the organization section. The "OrganizationDisplayName" is what must contain the maximum 30-character name that the organization wishes to be displayed to users, as well as the organization name that will be saved into the users IBMid record.

Example:

<md:Organization> <md:OrganizationName
xml:lang="en">IBM</md:OrganizationName> <md:OrganizationDisplayName xml:lang="en">IBM
Blueid</md:OrganizationDisplayName> <md:OrganizationURL xml:lang="en"/>
</md:Organization>

The OrganizationDisplayName must exist in SAML metadata, and it must be less than 30 characters.

Note: This "organization" section in SAML metadata is part of the SAML industry spec for metadata, but is considered optional. As such it may have to be manually added to the metadata that is generated by the organizations IdP.

Organizations’s Identity Provider (IdP) metadata

The organization must then provide IBM with the SAML metadata for its organization identity provider. This can be provided either via a URL to download the metadata, or sent in XML file format directly to the IBMid federation on-boarding contact.

Once the federating organization provides its SAML metadata, and the email domain information required above, IBM will respond with the IBMid service provider SAML metadata.