Setting up the identity providers

IBM webMethods iPaaS supports SSO that allows users to authenticate themselves against an identity provider (IdP) rather than obtain and use a separate username and password. After the IdP authenticates users, it informs IBM webMethods iPaaS about it, and the users can access the applications without having to sign in using their IBM webMethods iPaaS credentials.

About this task

Single Sign-On (SSO) is an authentication mechanism that allows users to access multiple applications by using a single ID and password. Explore the basic flow and configure the identity providers (IDPs).

Procedure

  1. Log on to IBM webMethods iPaaS as a user with Cloud-Tenant-Administrator privileges. You can grant access to external identity provider users. You can assign them the default IBM webMethods iPaaS roles. You can also assign them roles based on the group membership from the external identity provider.

    If you want to do the latter, go to Administration > Roles and note the role names.

  2. Create the URI for connecting the external identity provider to IBM webMethods iPaaS:
    • Go to Administration >Single-sign-on > Add identity provider.
    • b. Specify the identity provider display name and unique identifier.
    • Copy the auto-created URI that appears in the IBM webMethods iPaaS redirect URI field to the clipboard. You can use the icon at the far right of the field to copy.

    Configure your identity provider by using the following examples:

  3. Complete the configuration in IBM webMethods iPaaS and return to the metadata page and complete the fields. If you copy the external identity provider metadata URI or save the metadata to a file, choose to import and then specify the URI or file. Click Next.
  4. Go to the configuration page and complete the fields as necessary and click Next.
    Note: If you imported the external identity provider metadata, some of the fields are pre-populated with that corresponding metadata. If you do not import metadata, IBM webMethods iPaaS maps its fields to the external identity provider attributes as follows:
    Table 1. Mapping IBM webMethods iPaaS fields to external identity provider attributes
    Tab name Field name Description Identity provider attribute or field
    Metadata Single Sign-On Type SAML 2.0  
    Metadata Identity provider display name Friendly name of the identity provider.  
    Metadata Identity provider unique identifier for use in IBM webMethods iPaaS redirect URI A unique identifier for the identity provider.  
    Metadata IBM webMethods iPaaS URI URI that redirects external identity provider users to IBM webMethods iPaaS Copy the IBM webMethods iPaaS redirect URI to these fields:
    • Okta. Single sign-on URL and Audience URI fields.
    • Azure. Reply URL and Sign on URL fields.
    • ADFS. Auto-populated with the Relying Party> Endpoints > SAML Assertion Consumer Endpoints on importing the IBM® webMethods iPaaS descriptor to ADFS while adding the relying party.
    Configuration NameID policy format Format to use for the subjects of SAML assertions.
    • Okta. Set the Name ID format attribute.
    • Azure. Set the Name identifier attribute.
    • ADFS. Auto-populated with the NameID format set as the Outgoing name ID format during the setup of claim rules in the relying party in ADFS.
    Configuration Single sign-on service URL URL for the identity provider endpoint or service to which applications must submit service requests (SAML AuthnRequests). When creating the identity provider from scratch in IBM webMethods iPaaS, copy the value from this identity provider field to the IBM webMethods iPaaS field:
    • Okta. Identity Provider Single Sign-On URL field.
    • Azure. Login URL field.
    • ADFS. Copy the Location value under the SingleSignOnService tag in https://HOST NAME/FederationMetadata/2007-06/FederationMetadata.xml.
    Configuration(SAML advanced settings) HTTP-POST binding response Whether the identity provider uses HTTP-POST binding to respond to authentication requests instead of the default HTTP-Request rebinding. The default value is true.  
    Configuration (SAML advanced settings) HTTP-POST binding for AuthnRequest Whether the identity provider expects applications to use HTTP-POST binding to submit authentication requests instead of the default HTTP-Redirect binding. The default value is true.  
    Configuration (SAML advanced settings) Assertions signed (on/ off) Whether the identity provider signs SAML assertions and send the signed assertion. If you set the IBM webMethods iPaaS field to On, set this attribute as follows:
    • Okta. Set the Assertion Signature attribute to Signed.
    • Azure. Set the Signing Option attribute to the Sign SAML assertion.
    • ADFS. The assertion is signed by default.
    Configuration (SAML advanced settings) Assertions encrypted Whether IBM webMethods iPaaS expects an encrypted assertion from the identity provider If you set the IBM webMethods iPaaS field to ON, create the certificate as follows: i. Copy the Service Provider Descriptor URL from the Configuration tab in IBM webMethods iPaaS and open it in a browser.
    Note: This field is visible only after the Single sign-on profile is saved.
    Copy the content of the X509Certificate attribute from the response to a file, add the header —–BEGIN CERTIFICATE—– and the footer —–END CERTIFICATE—–, and save the file with the extension.cert. Set this attribute and upload the certificate:
    • Okta. Set the Assertion Encryption attribute to On and then upload the certificate.
    • Azure. Token Encryption section of the application’s page - upload the certificate and then set the Activate token encryption attribute to On.
    • ADFS. Auto-popluated on importing the IBM webMethods iPaaS descriptor to ADFS during the setup of the relying party. If updated later, in ADFS go to Encryption and add the new certificate.
    Configuration (SAML advanced settings) Validate signature Validation of SAML assertion signatures. If you set the IBM webMethods iPaaS field to On, copy the public certificate from the identity provider to the Validating X509 Certificates field. You can obtain the certificate in the following way:
    • Okta. Copy the X.509 Certificate from the View Setup Instructions link in the Sign-on tab of the application and remove the —–BEGIN CERTIFICATE—– header and the —–END CERTIFICATE—– footer. ii. Copy the X.509 Certificate by downloading the metadata file provided at the Identity provider Metadata link in the Sign-on tab of the application.
    • Azure. Go to the Azure Active directory > Enterprise applications > Symantec Web Security Service (WSS) > Single sign-on > SAML Signing Certificate and download the certificate that is provided at the Certificate (Base64) link.
    • ADFS. This field auto-populates if you import the federation metadata by using a file. If the Create from scratch option is used, then copy the content inside the tag in https://HOST NAME/FederationMetadata/2007-06/FederationMetadata.xml.
    Attributes Username Name of the SAML attribute that identifies the user. Always the NameID attribute value in the Identity provider (for example, an email address or username).
    Attributes Work email Name of the SAML attribute that provides the user’s email address.
    • Okta. Set the user.email attribute.
    • Azure. Set the user.mail attribute.
    • ADFS. In ADFS, go to Add Rule. In the Add Transform Claim Rule window, select LDAP Attribute as Email-Address and set the Outgoing claim type as the same value provided in IBM webMethods iPaaS.
    Attributes First name Name of the SAML attribute that provides the user’s first name.
    • Okta. Set the user.firstName attribute.
    • Azure. Set the user.givenname attribute.
    • ADFS. In ADFS, go to Add Rule. In the Add Transform Claim Rule window, select LDAP Attribute as Given Name and set the Outgoing claim type as the same value provided in IBM webMethods iPaaS.
    Attributes Last name Name of the SAML attribute that provides the user’s last name.
    • Okta. Set the user.lastName attribute.
    • Azure. Set the user.surname attribute.
    • ADFS. In ADFS, go to Add Rule. In the Add Transform Claim Rule window, select LDAP Attribute as Surname and set the Outgoing claim type as the same value provided in IBM webMethods iPaaS.
    Roles IBM webMethods iPaaS Roles Roles set in the Identity provider. The values are reflected in the SAML assertion. In the SAML assertion response, IBM webMethods iPaaS looks for a key named roles to get the list of roles.
    • Okta. Add a new key named roles under Group Attribute Statementsand set the value to the name of the groups.
    • Azure. In the User Attributes & Claims section, add a new key named roles and set the value to user.assignedroles.
    • ADFS. In ADFS, go to Add Rule. In the Add Transform Claim Rule window, select Send Claims Using a Custom Ruleand update the Custom rule section.

What to do next

On the Attributes page, type the user attribute names that you specified in the identity provider and click Next.
Note:
  • Whenever a user logs in, all user attributes are updated from the external identity provider.
  • You cannot use an external identity provider user as a technical user for API authentication. Instead, use an internal user for technical API calls.

On the Roles page, you can grant access to the identity provider users based on the following roles and save the identity provider configuration.

  • To assign default IBM webMethods iPaaS roles to the identity provider user, click Assign default IBM webMethods iPaaS roles to users. Later, you can go to individual IBM webMethods iPaaS products and modify the access.
  • To assign IBM webMethods iPaaS roles to identity provider users based on the group membership from the external identity provider, click Assign IBM webMethods iPaaS roles to users. Next, map the users to identity provider roles. Click the plus icon and select an IBM webMethods iPaaS role and type the name of the identity provider group that corresponds to the role. IBM webMethods iPaaS updates the user role assignments at each login. If an external-Identity provider role matches the SAML assertion, the role is added. If not, the role is removed.