Which is the right federation option for you?
In the past, IBM Cloud supported integration with customer's user directories by using IBMid SAML federation. In May 2020, IBM Cloud introduced an alternative method for clients to federate identities with their IBM Cloud account.
By default, when you create an account in IBM Cloud you use an IBMid for user identity. IBMid is the ID as a Service (IDaaS) from IBM used to access IBM web-based services, including IBM Cloud resources. The IBMid is based on your company's email address and a password that is managed by IBMid. IBMid allows you to federate to your own corporate user directory or a third-party Identity Provider (IdP) service that you might already use, such as Okta.
Federating to your own directory simplifies the process of adding users to your account, without requiring an IBMid with a separate password. However, there are cases where it might not be feasible for you to use IBMid to federate your corporate user directory. The alternative is to create an IBM Cloud App ID instance in your account and connect it to your chosen IdP.
This topic explains the differences between the following two methods:
- Federating with IBMid.
- Federating with your own instance of IBM Cloud App ID.
To decide which option is applicable to your use case, review the following sections.
Which SAML federation options exist in IBM Cloud?
IBM Cloud supports the following user types:
- Non-federated IBMid users
- Users with a valid email address can create an IBMid and let IBMid manage the password. Your company email domain is not federated with IBMid, and you choose to keep it as is. Any user that uses your email domain can create their own IBMid, and the password they create is managed by IBMid. They can create an IBM Cloud account and invite other users with an IBMid to their account. They can also access other IBM web offerings by using that same IBMid.
- Federated IBMid users
- Enterprise customers often connect their internal user directory, or IdP, with IBMid so that their employees don't need to manage an additional password. Instead, they can reuse their normal login to their IdP to log in to IBM web offerings, including IBM Cloud. Connecting an external IdP with IBMid is called federation, and the technical underlying protocol is called SAML. 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 App ID can also connect to an IdP. An App ID instance can connect to onlyone external IdP using SAML, and therefore a unique email address isn't required.
IBM Cloud account owners
To create an IBM Cloud account, you need an IBMid user that will be the IBM Cloud account owner. You can create this IBMid user during the IBM Cloud account registration process, or you use an existing IBMid user. We recommend creating the account by using a functional ID or service account with a valid email address, this can help simplify account ownership continuity in your organization.
For any additional members 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 IdP to your IBM Cloud account by using an IBM Cloud App ID service instance. All users that log in through that IBM Cloud App ID service instance are added to your account automatically, so you don't need to invite those users.
How do you onboard IBM Cloud account members?
IBM Cloud accounts have access to all IBMid users, federated and non-federated. IBMid users must 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 that log in by using this service instance can be member of this only one account. Those users will be automatically added to your IBM Cloud account when they authenticate the first time.
Comparing federation options
The following table compares 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 IdP with SAML.
| Feature | IBMid | App ID |
|---|---|---|
| Email address | Users must have a globally unique email address. For example, firstname.lastname@example.com. If your company's email domain is already federated, you can start configuring access to your account. If it's not already federated, a manual process with the IBMid federation team is required to establish federation. During the federation setup process, the customer collaborates with the IBMid federation team to define which email pattern matches with the IdP users. The decision to federate to your company's own user directory needs to involve the person in your company that can make company-wide decisions when it comes to connecting to external parties for identity services. You need to ensure that this person is included in the process. Federating with IBMid can have an impact on non-IBM Cloud web services that your company already uses with IBM. | This option requires the creation of an App ID instance. It is a self-service option with a low usage fee. Choosing this option requires a custom URL to log in to IBM Cloud. In addition, an App ID instance and configuration of the federation to your IdP is required for every IBM Cloud account. |
| Costs | Customers do not need to pay to use IBMid with or without federation. | IBM Cloud App ID instances have a low fee, with a free tier up to 1,000 users and 1,000 events (for example, logins). See the App ID page for more details. |
| Federation setup | Customers need to open a support case with IBMid Enterprise Federation to start the onboarding process. This is a manual process. | Customer creates an IBM Cloud App ID instance and configures it according to the documented steps. This process is self-service. |
| Federation maintenance (for example, certificate update) | Requires a manual interaction with the IBMid federation team. | The customer can update their IBM Cloud App ID instance on their own (for example, this step is self-service). |
| Federation scope | 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 using IBMid. | The federation has impact only on the IBM Cloud account in which the IBM Cloud App ID instance is configured to allow logins. It also does not impact any other IBM Cloud accounts or IBM SaaS offerings. |
| Account member onboarding | Users need to be invited by their email address. | Each user that can successfully log in to the configured IBM Cloud App ID instance will automatically be added to the IBM Cloud account. |
| Cross-account membership | IBMids can be members of multiple accounts. | Users can be members of one account only. Even if multiple IBM Cloud App ID instances federate to the same IdP, the users are treated as separate users in each account. |
| Use of SAML assertions in access group dynamic rules | Any SAML assertion sent by the IdP can be used in access group dynamic rules. | Any SAML assertion sent by the IdP can be used in access group dynamic rules. |
| Reliability | 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. | Any IBM Cloud App ID instance exists in one region. Failures in that region can prevent account members from being able to log in. Users that are already logged in are usually not affected by such a failure. |
| Login behavior | Users log in by using the central login page. | You need to use a special URL to log in to your IBM Cloud account. Your account administrator gets this URL from the IAM Identity providers page in the IBM Cloud console. |
Scenarios
For additional help deciding the correct option, review the common scenarios:
- Using a single IBM Cloud account
- A customer is using a single IBM Cloud account and no other IBM SaaS offerings. Since the customer is not using any other IBM SaaS offering or any other IBM Cloud account, they have no advantage in the federation scope capabilities or cross-account capabilities of IBMid. The number of users and logins are low, so the IBM Cloud App ID option doesn't incur costs for this account. The customer decides on IBM Cloud App ID as the federation option.
- Using IBM Cloud and other IBM SaaS offerings
- 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 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 gives all employees the ability to use IBM SaaS offerings and the IBM Cloud console by using your Identity Provider's password management and validation.
Resources
The following links help you implement the federation that you choose:
- IBMid Enterprise Federation Adoption Guide.
- The publicly available IBMid federation guide gives you an overview about the steps that are required to federate your Identity Provider and whom to contact to get the federation implemented. Be aware that you need an "IBM Sponsor" (for example, an IBM employee that works 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
- Follow 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. 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 use 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 work 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 rule 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.
- IBM Cloud Account Single Sign-on by 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.