Configuring the WebSphere Relying Party TAI

The WebSphere relying party TAI must be configured to trust tokens for the OpenID Connect (OIDC) provider to work properly.

About this task

The WebSphere relying party TAI is configured to trust tokens coming from the OIDC provider. In this way, only tokens that have been digitally signed by the authorization server at the identity provider will be trusted and validated at WebSphere. Once validated, the attribute that is present in the token that represents the identity of the user will be used to lookup the user’s profile in Connections.

For more information on custom properties that can be set on the WebSphere relying party TAI, see the support article from IBM on Open ID Connect, WebSphere traditional custom properties. For Connections mobile, see the section on Properties Required for a JWT Authentication Only Provider. This section can be used because the Connections mobile app will obtain a JWT from the Authorization server and then present that JWT to WebSphere when accessing a restricted resource.

To configure the TAI, perform the following steps:

Procedure

  1. As the WebSphere administrator, in the administrative console, click Security > Global security > Web and SIP security > Trust association.
  2. Click Interceptors > New to add an interceptor.
  3. For the interceptor class name, enter com.ibm.ws.security.oidc.client.RelyingParty
  4. Add the following properties and values.
    Note: A number of these property values can often be obtained from your OIDC providers configuration endpoint. See Accessing the OIDC provider configuration endpoint for more information.
    Table 1. WebSphere OpenId Connect Relying Party TAI parameters
    Property Value
    provider_1.useJwtFromRequest

    required
    provider_1.identifier

    cnx_azure

    This must be a unique name of an OIDC provider on this instance. Any name is acceptable as long as it does not conflict with other OIDC provider names.
    provider_1.issuerIdentifier

    This must match the “iss” claim from the JWT.​​​​​​​ You can determine the value from the issuer key found in OIDC discovery endpoint for your provider.

    For the Azure example, this would typically be in the form of

    https://login.microsoftonline.net/{​​​tenant_id}​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​/v2.0
    provider_1.jwkEndpointUrl

    Specifies the URL of the OpenID Providers JSON Web Key (JWK) set document that contains the signing key the Relying Party uses to validate the signature from the OpenID Connect provider.

    For the Azure example, this would typically be in the form of

    https://login.microsoftonline.com/%7Bteams_tenant_id%7D/discovery/v2.0/keys
    provider_1.signVerifyAlias

    This key is only required if your OP does not support a JWK Endpoint URL. This key specifies the alias of the certificate in the default truststore that can be used to verify the signature from the OP.

    You must import the public certificate used to sign the tokens into this truststore.
    provider_1.interceptedPathFilter

    /mobile/homepage/.*
    provider_1.audiences

    ALL_AUDIENCES
    provider_1.setLtpaCookie

    true
    provider_1.userIdentifier

    email

    This forces the connections server to use the email claim from the JWT as the identifier of the user. This must be set to a claim that is present in the JWT, and the value of the claim will be used to uniquely identify the user within the Connections profiles database. It is recommended to use a claim that contains the user’s email when each user has a unique email address defined within Connections.
    provider_1.useRealm

    defaultWIMFileBasedRealm

    This is the default realm that is used by WebSphere, but this value should match the Realm name that is defined in the WAS console under Global Security > Realm name .

  5. Add the OpenID Connect Relying Party TAI class to the global security property com.ibm.websphere.security.InvokeTAIbeforeSSO:
    1. Click Security > Global security and then click Custom properties.
    2. Check the list for com.ibm.websphere.security.InvokeTAIbeforeSSO. At the end of the existing value, add com.ibm.ws.security.oidc.client.RelyingParty.
      Note: This begins with a comma
    3. Click OK.
  6. Disable com.ibm.websphere.security.disableGetTokenFromMBean, as when this is enabled, the LptaToken2 may not be able to be used from different WebSphere clusters.
    1. Click Security > Global security .
    2. Click Custom properties.
    3. Find the property called com.ibm.websphere.security.disableGetTokenFromMBean
    4. Click and change the value from true to False.
    5. Save the configuration.
  7. Configure the trusted realms to include the JWT issuer:
    1. Click Security > Global security .
    2. In the User account repository section, click Configure.
    3. In the Related Items section, click Trusted authentication realms - inbound > Add External Realm.
    4. In the External realm name field, enter the issuer name that is used by the JWT. This should match the value that was entered for provider_1.issuerIdentifier .
    5. Click OK.
  8. Add the root signing certificate of the identity provider JWKS endpoint to the Default Trust Store:
    1. Click Security > SSL certificate and key management.
    2. Click Key stores and certificates.
    3. Select CellDefaultTrustStore and click Signer certificates.
    4. Click Retrieve from port.
    5. For the Host field, enter the host-name used by the JWK endpoint URL. For the Azure example, this would be login.microsoftonline.com.
    6. For the Port field, enter 443.
    7. For the Alias field, enter any unique alias name such as OIDCProvider.
    8. Click Retrieve signer information.
    9. i. Click OK and save the changes .
  9. Synchronize all nodes.
  10. Restart the WebSphere server.