User experience

By default, new IBMid EF configurations are configured at the email “domain level”, such that all new IBMids associated with the organization are created automatically via the IBMid JIT (“Just-In-Time”) provisioning service and are always authenticated through the partner’s identity provider.

Any partner IBMid user accounts which existed prior to establishing the IBMid EF configuration (and which use the standard IBMid native password-based authentication) can be converted to be authenticated by the partner IdP at the partner’s option.

Example, user test@blueid-test.com opens an application and must authenticate via IBMid sign in page. The RED ARROWS follow the non-federated user authentication flow. The BLUE ARROWS follow the federated authentication flow.
Flow diagram

Federated users enter their email address and click continue; at that point a lookup is made in the background of IBMid to verify if the email address/domain is associated with the user’s organization. The user is then redirected to their organization’s sign in experience. After authenticating successfully via the steps required by their organization, the user is returned back to IBMid with a "SAML assertion" attached. The IBMid system uses the email address in the "SAML assertion" to match them to an existing IBMid. Additionally, if an existing IBMid is not found, IBMid auto-provisions a new IBMid for the organizational user, based on the username information provided by the organization in the SAML assertion. Once this has been completed, they are returned to the originally requested IBM application as a fully recognized and authenticated IBMid user.

EF supports both Service provider-initiated (SP-initiated) sign on and Identity provider-initiated (IdP-initiated) sign on methods. For more details, please review the following sections below:

IBMid User Authentication vs IBM Applications Access

Often, EF is used in conjunction with specific IBM applications (for example, Planning Analytics, Sterling, etc). However, it is important that partners understand that creating a federated trust configuration with IBMid does not tie access to any specific IBM application. Providers may be used to creating federated identity relationships with specific applications. However, IBMid is not an application. It is an identity service which supports login for accessing a wide range of IBM applications. Just because a user can login to IBMid does not mean that user has access to a particular application. Access to a specific IBM application (entitlement) is controlled by the application itself. For example:
  • Any user that logs on to IBMid can access MyIBM (myibm.ibm.com)
  • To open support cases via the MySupport portal, a user requires a specific entitlement configured by IBM Support.
  • Access to Passport Advantage (PAO) requires the user’s ID to be specifically entitled based upon approval by a customer’s PAO Primary Contact.
  • To access IBM Planning Analytics (PA), an IBMid user must be configured into the appropriate PA workspace.
  • Specific authorizations granted via the IBM Cloud Console allow an IBMid user to manage IBM Cloud account resources.
The point of the above is that IBMid EF is used for authenticating users to IBMid, not to authorize access to any particular application. IBM applications control their own entitlements and it is not necessary for identity providers configured with IBMid EF to control access to specific IBM applications. Controlling individual IBM application access at the identity provider is a minimally effective security control and as a practical matter requires significantly more administrative overhead to maintain. Allowing all EF partner users (based on email domain) to login through the identity provider and leaving authorization/entitlement decisions under the control of applications has the following advantages:
  1. Partners can have full control of the IBMid authentication process for all its users, including password policy, implementation of multiple factors, etc.
  2. User authentication via EF provides partners with enhanced auditability and operational awareness of IBMid usage.
  3. Management of IBMid creation and configuration is greatly simplified.

Service provider-initiated (SP-initiated) sign on User Experience

  1. The user has an account at the service provider site.
  2. The user attempts to access the protected resource from the service provider.
  3. The service provider initiates a SAML authentication request to the identity provider. The service provider redirects the user's browser to the identity provider.
  4. The user signs in.
  5. The identity provider generates a SAML authentication response that asserts that the user is authenticated.
  6. The service provider validates the SAML authentication response.
  7. The user's browser is redirected to the service provider target URL and the user is authorized to access the requested resource.

Identity provider-initiated (IdP-initiated) sign on User Experience

  1. The user has an account at the identity provider site.
  2. The user signs in to the identity provider site or uses the identity provider single sign-on URL to access the protected resource from the service provider.
  3. The identity provider initiates a SAML authentication response that asserts that the user is authenticated.
  4. The service provider validates the SAML authentication response.
  5. The user's browser is redirected to the service provider target URL and the user is authorized to access the requested resource.

IBMid User re-authentication

The 'remember me’ function is available and it will remember its user’s IBMid after the user selects Continue.

Federated users will not be automatically re-authenticated to IBMid via the failover cookie after their sessions expire (default timeout is 30 minutes of inactivity and 1 hour total). Many federating companies have requested this feature to force a more frequent authentication. Once the IBM application or IBMid session time out occurs, any further authentication will be redirected back to your IdP for re-authentication. Whether the user is required to authenticate with your IdP again is controlled by your IdP's session lifetime settings. If 'remember me' is enabled for the user, and your IdP has a longer lifetime than IBMid, the user may not notice re-authentication to IBMid happening. Otherwise, the user will have to re-authenticate with IBMid again.