In the past, IBM Cloud supported integration with customer’s User Directories using IBMid SAML federation. In May 2020, IBM Cloud introduced a new way for customers to federate their users with their IBM Cloud account.
The following blog post shows the differences between both methods to help you decide if you want to connect your User Directory using IBMid or using a service instance of IBM Cloud App ID.
IBM Cloud supports the following user types:
To create an IBM Cloud account, you will need an IBMid user that will be the IBM Cloud account owner. You can create this IBMid user during the IBM Cloud account creation process, or you use an already existing IBMid user. This user can be a normal IBMid user or a federated IBMid user.
For any additional member of your IBM Cloud account, you have the option to use normal or federated IBMid users as IBM Cloud account members. Alternatively, you can connect your Identity Provider to your IBM Cloud account using an IBM Cloud App ID service instance. All users that log in through that IBM Cloud App ID service instance will be added to your account automatically — you do not need to invite those users.
IBM Cloud accounts have access to all IBMid users (federated and normal). IBMid users have to be invited to your IBM Cloud account. As a consequence, the same IBMid user can be member of multiple IBM Cloud accounts at the same time. In the IBM Cloud Console, the IBMid user can select the account in which this user is working.
During configuration of your IBM Cloud App ID service instance, you connect the service instance with your IBM Cloud account. Therefore, users logging in using this service instance can only be member of this one account. Those users will be automatically added to your IBM Cloud account, if they authenticate the first time. Using configuration options, you can also prevent AppID users from being onboarded automatically. Non-onboarded users can only work inside an IBM Cloud account if they assume a trusted profile (see section “Use of SAML assertions in Access Group Dynamic Rules” later).
The following list compares some characteristics of each federation option. In both cases, the assumption is that the customer connects either an IBMid or an IBM Cloud App ID instance with their Identity Provider via SAML.
To further help deciding for the right option, see some typical scenarios:
As the customer is not using any other IBM SaaS offering nor any other IBM Cloud account, they have no advantage in the federation scope capabilities or cross-account capabilities of IBMid. Also, the manual onboarding process with IBMid seems to be too complicated. The number of users and logins are quite low, so the IBM Cloud App ID option will not cause costs for this account. The customer decides on IBM Cloud App ID as the federation option.
IBM has a long-lasting and strong relationship with many customers. Those customers typically consume multiple IBM SaaS offerings, which require all customer users to use IBMid user accounts to work with those IBM SaaS offerings. In that case, all customer employees would have an advantage in using IBMid federation instead of federation based on IBM Cloud App ID. The IBMid federation will give all employees the ability to leverage IBM SaaS offerings and the IBM Cloud Console using your Identity Provider’s password management and validation.
The following links will help you implement the federation that you choose:
Check out the documentation to learn more about Identity and Access Management in IBM Cloud.