Which is the right federation option for you?

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.

Which SAML federation options exist in IBM Cloud?

IBM Cloud supports the following user types:

• Normal IBMid users: Users with a valid email address can create an IBMid and let the password be managed by IBMid.
• Federated IBMid users: Enterprise customers often connect their internal User Directory (“Identity Provider”) with IBMid so that their employees do not need to manage an additional password. Instead, they can reuse their normal login to their Identity Provider to also log in to IBMid. Connecting an external Identity Provider with IBMid is called federation, the technical underlying protocol is called SAML, and those users are often referenced as federated IBMid users. As IBMid is federating with multiple enterprise customers at the same time, one prerequisite of a successful federation is a unique email address for each IBMid user.
• IBM Cloud App ID users: Instances of the IBM Cloud service App ID can also connect to an Identity Provider. An App ID instance can only connect to one external Identity Provider using SAML, therefore there is no requirement for a unique email address.

IBM Cloud account owners vs. IBM Cloud account members

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.

How do you onboard IBM Cloud account members?

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

Which is the right federation option for you?

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.

Email address

• IBMid with federation to an Identity Provider: Users must have a globally unique email address (e.g., firstname.lastname@company.com). During the federation setup process, the customer defines together with the IBMid federation team which email pattern matches with the Identity Provider users.
• IBM Cloud App ID connected to an Identity Provider: No special requirement.

Costs

• IBMid with federation to an Identity Provider: Customers do not need to pay to use IBMid with or without federation. See IBMid Enterprise Federation for further details.
• IBM Cloud App ID connected to an Identity Provider: IBM Cloud App ID instances have a fee dependent on users and usage. See the App ID page for further details.

Federation setup

• IBMid with federation to an Identity Provider: Customers need to open a case at MySupport with IBMid Enterprise Federation to start an onboarding process. The following process is a manual process.
• IBM Cloud App ID connected to an Identity Provider: Customer creates an IBM Cloud App ID instance and configures it according to the documented steps. No other person is involved — this step is self-service.

Federation maintenance (e.g., certificate update)

• IBMid with federation to an Identity Provider: Requires a manual interaction with the IBMid federation team.
• IBM Cloud App ID connected to an Identity Provider: The customer can update their IBM Cloud App ID instance on their own (i.e., this step is self-service).

Federation scope

• IBMid with federation to an Identity Provider: IBMid federation applies to every service that uses IBMid. This means that if a customer onboards to IBMid federation, this applies to his employees when logging on to IBM Cloud, but also when using other IBM SaaS offerings that are leveraging IBMid.
• IBM Cloud App ID connected to an Identity Provider: The federation only has impact on the the IBM Cloud account in which the IBM Cloud App ID instance is configured to allow logins. It does not impact any other IBM Cloud accounts or IBM SaaS offerings.

Account member onboarding

• IBMid with federation to an Identity Provider: Users need to be invited by their email address. IBMid user can assume trusted profiles even without account onboarding (i.e. in those scenarios, no invitation need to happen).
• IBM Cloud App ID connected to an Identity Provider: Each user that can successfully log into the configured IBM Cloud App ID instance can automatically be added to the IBM Cloud account. The account administrator can also configure the App ID instance to prevent automatic onboarding. In that case, users can only assume trusted profiles to work inside the account.

Cross-account membership

• IBMid with federation to an Identity Provider: IBMids can be members of multiple accounts.
• IBM Cloud App ID connected to an Identity Provider: Users can be members of one account only. Even if multiple IBM Cloud App ID instances federate to the same Identity Provider, the users are treated as separate users in each account.

Use of SAML assertions in Access Group Dynamic Rules

• IBMid with federation to an Identity Provider: Any SAML assertion sent by the Identity Provider can be used in Access Groups Dynamic Rules.
• IBM Cloud App ID connected to an Identity Provider: Any SAML assertion sent by the Identity Provider can be used in Access Groups Dynamic Rules.

Use of SAML assertions in Trusted Profiles Trust Relationships

• BMid with federation to an Identity Provider: Any SAML assertion sent by the Identity Provider can be used in Trusted Profiles Trust Relationships. This way, users can work inside accounts without previous onboarding.
• IBM Cloud App ID connected to an Identity Provider: Any SAML assertion sent by the Identity Provider can be used in Trusted Profiles Trust Relationships. This way, users can work inside accounts without previous onboarding.

Reliability

• IBMid with federation to an Identity Provider: IBMid is a global service with a dedicated operations team. In case of an outage in a data center, IBMid can failover to a different data center.
• IBM Cloud App ID connected to an Identity Provider: Any IBM Cloud App ID instance exists in one region. Failures in that region can prevent account members from being able to log in. Already-logged-in users are usually not affected by such a failure.

Login behavior

• IBMid with federation to an Identity Provider: Users log in using the central login page.
• IBM Cloud App ID connected to an Identity Provider: You need to use a special URL to log into your account. Your account administrator will get this URL from the IAM Identity Provider configuration page.

Scenarios

To further help deciding for the right option, see some typical scenarios:

Scenario 1: A customer is using a single IBM Cloud account and no other IBM SaaS offerings

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.

Scenario 2: A customer is using IBM Cloud and other IBM SaaS offerings

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.

Resources

The following links will help you implement the federation that you choose:

• IBMid Enterprise Federation: This website gives you an overview about the steps required to federate your Identity Provider and whom to contact to get the federation implemented. Be aware that you need an “IBM Sponsor” (i.e., an IBM employee who will work as main contact between you and the IBMid team).
• IBM Cloud Self-Service Federation for External Identity Providers: Announcement for the IBM Cloud IAM feature to federate with an Identity Provider through SAML using IBM Cloud App ID.
• Enabling authentication from an external identity provider: This documentation describes the steps necessary to integrate an IBM Cloud App ID service instance with IBM Cloud IAM so that your users can use your IBM Cloud account without creating IBMids. Please review the section Setting IAM-specific attributes in App ID tokens to make sure that your users are correctly onboarded and displayed inside your IBM Cloud account.
• Control access to cloud resources: This tutorial describes how to leverage Dynamic Rules in Access Groups so that you automate permission assignments based on attributes that your Identity Provider is sending to IBM Cloud via SAML. The tutorial itself was written for IBMid federation, but the same concept and steps also works with IBM Cloud App ID based federation.
• Using App ID instances to build dynamic rules in access groups: In case you plan to use Dynamic Rules with IBM Cloud App ID-based federation, make sure to use the correct syntax for the “Identity Provider” setting inside the Dynamic Rule. The section in the link is describing how to build the correct “Identity Provider” identifier.
• Use Trusted Profiles to simplify User and Access Management: See how your IBMid or App ID users can work inside your account with clear distinct work functions – without account onboarding.
• IBM Cloud Account Single Sign-on using IBM Cloud App ID and Microsoft Azure AD: This blog entry shows the whole process of integrating Microsoft Azure Active Directory with IBM Cloud using IBM Cloud App ID.

Check out the documentation to learn more about Identity and Access Management in IBM Cloud.