Requirements for SSO

IBM assumes EF partners have the appropriate knowledge of SAML and skills required to administer their own Identity Provider (IdP) configurations.

Additionally, the organization’s IdP should meet the following technical requirements:
  1. The organizational identity provider must support SAML 2.0, and be able to support signed SAML assertions.
  2. While identity provider-initiated flows are allowed and supported, service provider-initiated flows are highly preferred for the most optimal user experience.
  3. Transient and persistent name identifier types are not supported.
  4. The SAML "NameID" returned by the organization's identity provider must be set to equal the valid email address for the organizational users email address and format:emailAddress
  5. The email address for the organization must be valid
  6. The following attributes "uid" and "groupid" will be ignored and removed from SAML assertion, please make sure your IdP does not use them. These attributes are not case sensitive.
  7. IBMid does not support secondary SAML SSO certificate rotation. In the case of a SAML SSO certificate renewal, the primary (default) certificate set to expire must be updated on both IBM’s side and the organization’s identity provider side simultaneously to prevent issues with IBMid user authentication via SSO.
  8. CA issue certificates are required to have CRL (Certificate Revocation List). In case your signing certificate has CRL, the URL must be public so the IBM server can reach them.
  9. Self-signed certificate cannot have Basic Constraints set to CA type.
  10. CRL validation - As part of IBM security standards we have a CRL (Certificate Revocation List) validation procedure running every 30 minutes.
  11. The following 4 SAML Attributes must be provided in the SAML assertion, with these exact attribute names: 1) firstName, 2) lastName, 3) country 4) emailAddress. NOTE: These attributes are case sensitive. For country, the expectation is to receive 2 characters per ISO Alpha-2 standard. (For example : US for United States, AU for Australia, GB for United Kingdom). These required SAML attributes will be mapped to OpenID Connect standard claim per OIDC specification, see table below. Any additional attributes provided by the organization in the SAML assertion will be sent through to the end IBM cloud service being used by the user but will not be persisted in the IBMid system in any way. Country attribute cannot be excluded, and it must always be a required value. IBM operates globally and we must comply with laws around embargo’s countries. This is one of our ways to be compliant.
    SAML Assertion attribute Comments OIDC ID Token Claim
    emailAddress Required - Maxlength 80. Validated as email format with regex (see below) email, ext.emailAddress
    lastName Required - Maxlength 35 family_name
    firstName Required - Maxlength 35 given_name
    country Required - 2 CHARS. Example: US for United States address.country

    Format according to our Country List

  12. IBMid does not support userid or username change. In this case the federating organization must create a new IBMid account (auto-provision or manually registration) to match the organization email domain.
  13. When a Federation certificate is revoked, that certificate is considered as untrustworthy by the Certificate Authority. Continuing to allow your federation login with revoked certificate is a security risk. You can check if your signing certificate was revoked or even added by mistake. As you own your signing certificate, you can:
    • Request IBM to disable your federation and this will impact all federated users preventing them from authenticating with your own company credentials when accessing any IBM product.
    • Decide to keep the way it is and assume the risk of using a signing certificate that has a CRL validation failure.
    • Keep using the current Signing certificate with CRL validation failure while providing a new certificate. Please send us the new certificate at least 5 business day before you deploy it in our IdP environment so that IBM can update your federation and not cause any outage or issue for your federated users.