Behavior of OIDClient has changed with 23.0.0.10 if authCache does not contain entry for current user - New HTTP session is created during reauthentication

[UlrichLohrmann]

Describe the bug
We have an application that uses OpenIDConnect client for user authentication. No explicit AuthCache timeout is configured, so default value of 600s is used. If a user logs in, then does not have any interaction with the application for approximately 15 minutes and then continues interaction with the application (for example triggers HTTP GET or POST), no entry for the current user is found in Auth Cache which leads in a reauthentication using the current OIDC provider.

So far so good.

With Open Liberty version 23.0.0.9 and earlier after successful OIDC reauthentication, the value of the HTTP session cookie is unchanged while with 23.0.0.10 and newer versions after successful OIDC reauthentication the value of the HTTP session cookie has changed. As a result, the current user looses his/her session and current work.

Steps to Reproduce
Having an application with OIDC authentication and Open Liberty version >= 23.0.0.10

• Find out the current timeout value of Auth Cache (Default 600s)
• Login using OIDC authentication
• Check value of HTTP session cookie
• No interaction for about (authCacheTimeout + (authCachetimeout / 2)) -> 900s in case of default Auth cache timeout
• After wait time has expired continue using the application and watch network traffic using Browser`s Developer tools
• Check value of HTTP session cookie -> after successful reauthentication using OIDC provider the value has changed

Expected behavior
No change of value of HTTP Session cookie after successful OIDC reauthentication if no entry for current user is found in AuthCache

Diagnostic information:

• OpenLiberty Version: >= 23.0.0.10
• Affected feature(s) [OIDC Client]
• Java Version: [OpenJDK 64-Bit Server VM, version 11.0.22+7 (en_US)]

''Additional information**

• Reducing the value of AuthCache.timeout for example to "2m" reduces wait time until reauthentication occurs (about 4 minutes with AuthCache.invalidate="2m").
• Changing the value of AuthChache.timeout to be > timeout HTTP Session seems to be a valid workaround. In this case, no OIDC reauthentication is executed as a valid entry if found for each request in AuthCache.

Could you please verify described behavior and check wheter or not this behavior is expected?

Best regards Ulrich

[ayoho]

Hi, @UlrichLohrmann. Thanks for opening an issue. We'll get the SSO and Core Security teams to have a look.

[arkarkala]

@UlrichLohrmann Are you using Liberty OP or a third party? can you provide the relevant configs (OIDC, authcache, ltpa etc)? And when you say "successful OIDC reauthentication" were you prompted again? We might also need some traces later but will wait for the above info. first.

[UlrichLohrmann]

@arkarkala We use Open Liberty "Java EE 8" Version as offered on the official download page. In addition, we have installed the features "openidconnectclient-1.0", "wsSecurity-1.1" and "passwordUtilities-1.0". Open Liberty and the application are executed using actual version of Adoptium Temurin JRE 11 in a container using podman in rootless mode. The bahavior with 23.0.0.10 and later ist the same for the application beeing executed in a podman container or on a Windows workstation without container, simply beeing executed using "java" as native process. In front of the Open Liberty container we have an IBM HTTP Server 8.5.5.24 that delegates all calls to the Open Liberty Container.

What I mean with "successful OIDC reauthentication" is that after waiting 15 Minutes without interaction with the application I click an arbitrary link that triggers a HTTP request. As a result I get HTTP Content with a JavaScipt that triggers a redirect to the OIDC provider (a keycloack). This HTTP request is answered by a redirect to the original link (the click after the wait time). No prompt for Username od password here.

The Open Liberty configuration does not contain explicit configuration elements for "authCache" and "ltpa". The defaults are used here.

The current openIdConnectClient configuration is:

<openidConnectClient id="..." httpsRequired="true"
  userIdentifier="..." 
  clientId="..."
  clientSecret="..."
  authorizationEndpointUrl="..."
  tokenEndpointUrl="..."
  signatureAlgorithm="RS256"
  jwkEndpointUrl="..."
  uniqueUserIdentifier="..."
  issuerIdentifier="..."
  groupIdentifier="..." 
  sslRef="..."
  responseType="code" 
  authFilterRef="..."
  userIdentityToCreateSubject="sub" 
  grantType="authorization_code"
  userInfoEndpointEnabled="false" 
  validationMethod="introspect" 
  inboundPropagation="none" 
  tokenReuse="false" 
  createSession="true" 
  realmIdentifier="..." 
  scope="openid profile" 
  redirectToRPHostAndPort="..."
  accessTokenCacheTimeout="5m"
  allowCustomCacheKey="true">
</openidConnectClient>

I can provide a trace with the trace specification "=info:com.ibm.ws.session.=all:com.ibm.ws.webcontainer=all:com.ibm.wsspi.webcontainer=all" for the working case (23.0.0.9 and earlier) as well as for the non-working case (23.0.0.10 and later). As these traces may contain sensitive data I need a secure way to provide the information. Posting traces here is unfortunately not an option.

Hope that helps.

Best regards UIlrich

[Zech-Hein]

Hi @UlrichLohrmann ,

We believe your problem should be fixed by this PR: https://github.com/OpenLiberty/open-liberty/pull/27655

That change was delivered into the 24.0.0.3 release which was published today.

Could you try updating to 24.0.0.3 to confirm that fixes the issue?

[UlrichLohrmann]

Hi @Zech-Hein,

thank you for your reply. I verified the behavior on my Windows workstation with 24.0.0.3 and now it works as expected. No new session is created after a new interaction after waiting 15 minutes with no interaction. So PR #27655 seems to fix the issue.

Thank you all for helping me on this issue.

Best regards Ulrich