IBM Support

TroubleShoot: OpenID Connect, WebSphere Liberty

Troubleshooting


Problem

Use this document to troubleshoot Liberty OIDC.  This document contains troubleshooting information for the OpenID Connect (OIDC) feature in WebSphere® Application Server Liberty. This document can help address common issues with this component before you call IBM support and save you time.

Resolving The Problem

Component:
Topic:
Overview

This topic contains error messages and common issues that require an OpenID Connect trace to determine the root cause of the problem. The instructions to obtain an OpenID Connect trace are in the 'Collecting data manually' section of the Collect data tab. If a trace string required for a specific problem is different than what is shown on the Collect data tab, the trace string is noted in the steps to diagnose the problem. In the rest of this document, 'OpenID Connect' is referred to as 'OIDC'.

 

How do I set up the Liberty OIDC feature?

For information on how to to set up your server to protect a resource by using the Liberty OIDC feature, see the articles in the IBM Documentation in the following table:

IBM Docs link
General OpenID Connect
Client Configuring an OpenID Connect Client in Liberty
Provider Configuring an OpenID Connect Provider in Liberty


 

Where do I find the custom properties for the Liberty OIDC feature?

The custom properties for the Liberty OIDC feature can be found in the IBM Documentation, use the the links in the following table:
 
IBM Docs link
Client openidConnectClient - OpenID Connect Client (openidConnectClient)
Provider openidConnectProvider - OpenID Connect Server Provider (openidConnectProvider)


 

Are there resources for learning OIDC for Liberty besides IBM Docs?

The following links are resources for learning about Liberty OpenID Connect outside IBM Docs:
 
Source
Link
DeveloperWorks Using OpenID Connect in WebSphere Application Server Liberty Profile
YouTube™ OpenID Connect on Liberty
IBM Advantage Blog WebSphere Liberty makes it easier to build OpenID Connect security services


 

How can I tell if a trace is from server startup?

IBM support requires that traces be gathered from server startup. If you want to make sure that your traces are gathered from server startup, check for the following string in your trace:
 
Search string
Full message
smarter planet CWWKF0011I: The server {0} is ready to run a smarter planet.


 

How do I find my OIDC client configuration in a trace?

If you have a trace from application server startup, you can find the raw OIDC feature properties by searching for the following string in an OIDC trace:

 
processProtectedString

Example:
 
[4/23/17 15:35:18:236 CST] 00000011 OidcClientCon > processProtectedString Entry
                                          {service.vendor=IBM, userIdentityToCreateSubject=upn, disableLtpaCookie=false, authnSessionDisabled=true, disableIssChecking=false, includeIdTokenInSubject=true, component.id=283, config.displayId=openidConnectClient[XXYYZ], httpsRequired=true, uniqueUserIdentifier=uniqueSecurityName, clockSkew=300000, allowCustomCacheKey=true, reAuthnCushion=0, tokenEndpointAuthMethod=post, component.name=com.ibm.ws.security.openidconnect.client.oidcClientConfig, service.pid=com.ibm.ws.security.openidconnect.client.oidcClientConfig_33, signatureAlgorithm=RS256, validateAccessTokenLocally=true, clientId=c344530b-0c12-4b6c-a1ff-ff4afff192ff, reAuthnOnAccessTokenExpire=true, validationMethod=introspect, groupIdentifier=groupIds, jwkEndpointUrl=https://login.company.com/np.abc.com/discovery/keys, encodeParameters=true, hostNameVerificationEnabled=false, authorizationEndpointUrl=https://login.company.com/np.abc.com/oauth2/authorize, tokenEndpointUrl=https://login.company.com/np.abc.com/oauth2/token, config.overrides=true, config.id=com.ibm.ws.security.openidconnect.client.oidcClientConfig[XXYYZ], id=XXYYZ, inboundPropagation=none, scope=openid, config.source=file, isClientSideRedirectSupported=true, nonceEnabled=false, oidcclientRequestParameterSupported=true, realmIdentifier=realmName, initialStateCacheCapacity=3000, createSession=true, service.factoryPid=com.ibm.ws.security.openidconnect.client.oidcClientConfig, trustStoreRef=myTrustStore, grantType=implicit, issuerIdentifier=https://login.company.com/np.abc.com/, mapIdentityToRegistryUser=false, trustAliasName=trusted01}

The resolved properties show up a little later in the trace. Example:
 
[4/23/17 15:35:18:331 CST] 00000011 OidcClientCon 3 id: XXYYZ
[4/23/17 15:35:18:331 CST] 00000011 OidcClientCon 3 grantType: implicit
[4/23/17 15:35:18:331 CST] 00000011 OidcClientCon 3 responseType:id_token token
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 scope: openid
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 clientId: c344530b-0c12-4b6c-a1ff-ff4afff192ff
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 redirectToRPHostAndPort: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 userIdentifier: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 groupIdentifier: groupIds
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 realmIdentifier: realmName
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 realmName: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 uniqueUserIdentifier: uniqueSecurityName
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 tokenEndpointAuthMethod: post
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 userIdentityToCreateSubject: upn
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 mapIdentityToRegistryUser: false
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 oidcclientRequestParameterSupported: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 validateAccessTokenLocally: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 disableLtpaCookie:false
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 trustAliasName: trusted01
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 httpsRequired: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 isClientSideRedirectSupported: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 nonceEnabled: false
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 sslRef: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 signatureAlgorithm: RS256
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 clockSkew: 300
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 authorizationEndpointUrl: https://login.company.com/np.abc.com/oauth2/authorize
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 tokenEndpointUrl: https://login.company.com/np.abc.com/oauth2/token
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 validationEndpointUrl: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 initialStateCacheCapacity: 3000
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 issuerIdentifier: https://login.company.com/np.abc.com/
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 trustStoreRef: myTrustStore
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 hostNameVerificationEnabled: false
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 includeIdTokenInSubject: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 allowCustomCacheKey: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 authContextClassReference:
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 authFilterRef: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 authFilterId: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 jsonWebKey: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 jwkEndpointUrl: https://login.company.com/np.abc.com/discovery/keys
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 prompt: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 createSession: true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 inboundPropagation: none
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 validationMethod: introspect
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 headerName: null
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 authnSessionDisabled:true
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon 3 disableIssChecking:false
[4/23/17 15:35:18:332 CST] 00000011 OidcClientCon < processConfigProps Exit
[4/23/17 15:35:18:333 CST] 00000011 OidcClientCon > isValidConfig Entry
[4/23/17 15:35:18:333 CST] 00000011 OidcClientCon < isValidConfig Exit
true
[4/23/17 15:35:18:333 CST] 00000011 OidcClientCon > getId Entry
[4/23/17 15:35:18:333 CST] 00000011 OidcClientCon < getId Exit
XXYYZ
[4/23/17 15:35:18:333 CST] 00000011 OidcClientCon I CWWKS1700I: OpenID Connect client XXYYZ configuration successfully processed.
 

Does the OIDC RP use the JVM proxy settings?

The OpenId Connect RP does not make use of the proxy settings in the JVM (https.proxyHost, https.proxyPort, etc).


If you're using an outbound proxy, the OpenId Connect RP does not provide a means to route requests through a proxy host automatically:
  • If you must use a proxy to access the OpenId Connect Provider (OP), the value that you enter for any OP related URL property must contain the proxy host and port, not the external OP host and port.
  • In most cases, you replace the OP host and port with the proxy host and port.
  • The URL that you enter must be visible to both the RP and the client (browser or application).
  • For further guidance on how to determine the correct URL to use, contact your proxy administrator.
 

How do you set up the Liberty OIDC OP for RS256?

Both the Liberty OpenID Connect RP and OP default to HS256 (HMAC with SHA-256) for the signature algorithm. The OpenID Connect specification requires support of the RS256 (RSA Signature with SHA-256) algorithm. Support for the HS256 algorithm is not mandatory in the OpenID Connect specification and it is not supported by many OpenID Providers.


For instructions on how to update your Liberty OIDC OP to use RS256, see the Configuring an OpenID Connect Provider to use the RSA-SHA256 algorithm for signing of ID tokens topic in IBM Docs.
 

How do you set up the Liberty OIDC RP for RS256?

Both the Liberty OpenID Connect RP and OP default to HS256 (HMAC with SHA-256) for the signature algorithm. Your RP signature algorithm must match the OP's signature algorithm and many OPs do not support HS256. To update your Liberty OIDC RP to use RS256, do the following:

  1. Edit the server.xml for your OpenID Connect RP.
  2. To the openidConnectClient element, add the following attribute/value pair:
    signatureAlgorithm="RS256"
  3. Do at least one of the following:
    • If your OP supports a JWK endpoint, configure your RP to use it:
      • Add the following attribute to your openidConnectClient configuration:
        jwkEndpointUrl Specifies the OP's JWK endpoint URL.
    • Configure the RP to use a local key:
      • Add the following attributes to your openidConnectClient configuration:
        trustStoreRef The keystore that contains the public key necessary for verifying the signature of the ID token.
        trustAliasName Key alias name to locate public key for signature validation with asymmetric algorithm. The public certificate of the OP's private key that was used to produce the signature.
 

You are challenged to re-login to a Liberty server when you aren't expecting it and more than one collective is in use

Background

In the default configuration, a Liberty server uses LTPA cookies. If your Liberty collectives are using LTPA cookies, read on.

If there is an LTPA cookie in the browser, the server has to validate it. If the cookie cannot be validated, the user is challenged to re-login. If the cookie was created by a server in another collective, there are several reasons why you get this error:

  • You intend the collectives to act independently, but a login to collective2 clobbers the login to collective1
    Solution
  • There is a cache key put in the LTPA cookie for collective1, which does not exist in collective2.
    You see the following error on collective2:
    com.ibm.ws.security.authentication.AuthenticationException: Custom cache key missed authentication cache. Need to re-challenge the user to login again.

    Solution
    • This approach requires Liberty 21.0.0.1 or later.
    • Change or add the following attributes in your openidCientConfiguration in server.xml:
      • allowCustomCacheKey="false"
  • The collectives use the same registry, but the user was not mapped to the registry in collective1.
    You see the following error on collective2:
    CWWKS1106A: Authentication did not succeed for the user ID user1@google.com. An invalid user ID was specified.

    Solution
    • Change or add the following attributes in your openidCientConfiguration in server.xml:
      • mapIdentityToRegistryUser="true"
  • The collectives use different registries.
    You see the following error (the same one as previous, but the solution is different):
    CWWKS1106A: Authentication did not succeed for the user ID user1@google.com. An invalid user ID was specified.

    Solution
    • See the solution for When you login with OIDC, then the LTPA cookie is sent to another Liberty collective, you get a CWWKS1106A error later in this document.
 

When you login with OIDC, then the LTPA cookie is sent to another Liberty collective, you get a CWWKS1106A error

Problem

Using the default OIDC configuration, when a user logs into a Liberty for an OIDC protected resource, if the LTPA cookie is used by a Liberty server in another collective, you might see an error similar to the following:

CWWKS1106A: Authentication did not succeed for the user ID user1@google.com. An invalid user ID was specified.

Solution

Do one of the following:

  • Configure your Liberty collectives to map OIDC users to the registry.
    • This approach requires Liberty 21.0.0.1 or later.
    • Change or add the following attributes in your openidCientConfiguration in server.xml:
      • mapIdentityToRegistryUser="true"
      • allowCustomCacheKey="false"
  • Configure your Liberty collectives to use JWT for the SSO cookie instead of LTPA.
  • Configure your Liberty collectives to use the OIDC access token in the Subject for user verification instead of the user registry.

    The requirement for this approach is that both the id_token and access_token contain the same subset of claims that can be used to create a new Subject.

    Using the following openidClientConfiguration settings, the access_token is embedded inside LTPA cookie. The server first decrypts the LTPA cookie. If cookie is originally created by the server, the Subject is retrieved from cache. If the LTPA cookie was created by another server, the server tries to use the access_token first, and then fall back to an OpenID Connect login challenge if the access_token validation with the OP fails.

    1. Change or add the following attributes in your openidCientConfiguration in server.xml:
      • accessTokenInLtpaCookie="true"
      • inboundPropagation="supported"
    2. Add one of the following pairs to your openidCientConfiguration
      • validationMethod="introspect"
      • validationEndpointUrl=(introspection url)
      -or-
      • validationMethod="userinfo"
      • validationEndpointUrl=(userinfo url)
    3. Configure all the Liberty servers to use the same LTPA key.
 

I'm in a login loop

If the requests to your OIDC protected application end up in a login loop, your browser might be blocking the OIDC cookies.  Try setting the SiteSite attribute of the WebAppSecurity element in your security.xml file to Lax or None. 
You can read more about how you can control how Liberty sets the SameSite attribute on cookies at Setting the SameSite attribute on cookies with Open Liberty.
 

Cookie “WAS_12345678” does not have a proper “SameSite” attribute value.

In the FireFox browser, you might encounter a warning that is similar to this one for the LTPAToken2, JWT, or WAS_* cookies:
Some cookies are misusing the recommended “SameSite“ attribute:
- Cookie “WAS_12345678” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite for navigator request
Action:

Note:

This document uses the term WebSphere traditional to refer to WebSphere Application Server v9.0 traditional, WebSphere Application Server v8.5 full profile, WebSphere Application Server v8.0 and earlier, WebSphere classic, traditional WebSphere, traditional WAS and tWAS.
 

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Component":"Security","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF013","label":"Inspur K-UX"},{"code":"PF014","label":"iOS"},{"code":"PF016","label":"Linux"},{"code":"PF022","label":"OS X"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"},{"code":"PF035","label":"z\/OS"}],"Version":"18.0.0.x;19.0.0.x","Edition":"Liberty","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"}}]

Document Information

Modified date:
26 March 2024

UID

swg21998067

Page Feedback