Add override of jwt context-root in openidConnectClient feature

[bpaskin-ibm]

Enabling openidConnectClient allows for overriding certain context roots associated with the functions of the OIDC Client, name the oidcclient context root. However, this does not allow for the overriding the jwt context root. This can lead to issues when there are several application servers that need load balancing but only some should handle certain jwt requests.

[AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/jwt/

It would be helpful to allow an override of this context root in the openidConnectClient configuration stanza with a property of jwtUri that would take the value and override the default jwt context root.

[teddyjtorres]

Hi. The jwt context root is part of the jwt-1.0 feature. Please elaborate on how the fixed context root causes the issues.

Regards.

[bpaskin-ibm]

@teddyjtorres The context root could be excluded too, as a solution.

The issue is when the following scenario is used:

client > web/plugin (dynamic routing) > app server1

The client logons to OIDC using App Server1 which communicates to the OID Provider and returns an opaque token, but we build a token using the jwt-1.0 feature to the client. The client then calls App Server2 using the the new token

client (passing token) > web server/plugin > App Server2

when App Server2 tries to validate the token it is going to call the web server with the jwkEndpointUrl. Since both App Servers have /jwt enabled the request may route back to App Server2 and fail since it does have the information necessary about the provider.

Brian

[brutif]

I'm not sure changing the ctx root for /jwt would fix it, couldn't the reverse still occur, client --> web plugin > appserver2 --> /jwt-new-and-improved then fails on subsequent load balancing to appserver1?. Maybe the question is if there is any way for the provider to be more than a singleton? I'm not well versed on the plugin, would it always route to the one server hosting /jwt-new-and-improved?

[bpaskin-ibm]

@brutif I am not sure I follow. Assume that we turn off the /jwt on App Server2. When validating all requests from App Server2 would go through the web server to App Server1. If the user is still hitting App Server1 it would still validate against the OID Provider.

Brian

[bpaskin-ibm]

@teddyjtorres if jwt-1.0 is the way it is activated, then there is a problem with the openidConnectClient-1.0 feature:

[10/12/20, 16:01:43:816 EDT] 00000021 com.ibm.ws.kernel.feature.internal.FeatureManager            A CWWKF0012I: The server installed the following features: [appSecurity-2.0, distributedMap-1.0, federatedRegistry-1.0, jndi-1.0, json-1.0, jsp-2.2, ldapRegistry-3.0, localConnector-1.0, oauth-2.0, openidConnectClient-1.0, servlet-3.0, ssl-1.0].
[10/12/20, 16:01:43:817 EDT] 00000021 com.ibm.ws.kernel.feature.internal.FeatureManager            I CWWKF0008I: Feature update completed in 2.238 seconds.
[10/12/20, 16:01:43:817 EDT] 00000021 com.ibm.ws.kernel.feature.internal.FeatureManager            A CWWKF0011I: The OIDC server is ready to run a smarter planet. The OIDC server started in 3.893 seconds.
[10/12/20, 16:01:43:959 EDT] 00000039 com.ibm.ws.webcontainer.osgi.webapp.WebGroup                 I SRVE0169I: Loading Web Module: OpenID Connect Client Redirect Servlet.
[10/12/20, 16:01:43:961 EDT] 00000037 com.ibm.ws.webcontainer.osgi.webapp.WebGroup                 I SRVE0169I: Loading Web Module: com.ibm.oauth.test.war.
[10/12/20, 16:01:43:963 EDT] 00000037 com.ibm.ws.webcontainer                                      I SRVE0250I: Web Module com.ibm.oauth.test.war has been bound to default_host.
[10/12/20, 16:01:43:963 EDT] 00000039 com.ibm.ws.webcontainer                                      I SRVE0250I: Web Module OpenID Connect Client Redirect Servlet has been bound to default_host.
[10/12/20, 16:01:43:965 EDT] 00000037 com.ibm.ws.http.internal.VirtualHostImpl                     A CWWKT0016I: Web application available (default_host): http://localhost:9080/oauth2/
[10/12/20, 16:01:43:968 EDT] 00000039 com.ibm.ws.http.internal.VirtualHostImpl                     A CWWKT0016I: Web application available (default_host): http://localhost:9080/oidcclient/
[10/12/20, 16:01:43:996 EDT] 0000003c com.ibm.ws.session.WASSessionCore                            I SESN8501I: The session manager did not find a persistent storage location; HttpSession objects will be stored in the local application server's memory.
[10/12/20, 16:01:43:996 EDT] 0000003b com.ibm.ws.session.WASSessionCore                            I SESN8501I: The session manager did not find a persistent storage location; HttpSession objects will be stored in the local application server's memory.
[10/12/20, 16:01:44:001 EDT] 0000003b com.ibm.ws.session.WASSessionCore                            I SESN0176I: A new session context will be created for application key default_host/oidcclient
[10/12/20, 16:01:44:001 EDT] 0000003a com.ibm.ws.session.WASSessionCore                            I SESN0176I: A new session context will be created for application key default_host/oauth2
[10/12/20, 16:01:44:015 EDT] 0000003b com.ibm.ws.util                                              I SESN0172I: The session manager is using the Java default SecureRandom implementation for session ID generation.
[10/12/20, 16:01:44:027 EDT] 0000003a com.ibm.ws.util                                              I SESN0172I: The session manager is using the Java default SecureRandom implementation for session ID generation.
[10/12/20, 16:01:44:073 EDT] 00000038 com.ibm.ws.webcontainer.osgi.webapp.WebGroup                 I SRVE0169I: Loading Web Module: com.ibm.ws.security.jwt.
[10/12/20, 16:01:44:073 EDT] 00000038 com.ibm.ws.webcontainer                                      I SRVE0250I: Web Module com.ibm.ws.security.jwt has been bound to default_host.

[teddyjtorres]

The jwt-1.0 and the openidConnectClient-1.0 features are independent. For jwt-1.0, this is the documentation the endpoints provided,

https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/twlp_sec_build_jwt.html

For openidConnectClient-1.0, these are the endpoint provided,

https://www.ibm.com/support/knowledgecenter/SSAW57_liberty/com.ibm.websphere.wlp.nd.multiplatform.doc/ae/rwlp_oidc_endpoint_urls.html

A load balancing scenario would require similar configuration across participating servers. That means that the jwtBuilder configurations must be the same, sharing the same public and private keys. Also ensure that the jwkEnabled="false" in the jwtBuilder to disable automatic generation of JWKs, so that the same JWKs can be retrieved from any server.

[bpaskin-ibm]

@teddyjtorres the issue is that the openidConnectClient-1.0 features is enabling the /jwt endpoint. According to the KC docs this should not be happening.

[teddyjtorres]

The openidConnectClient-1.0 feature includes the oauth-2.0, which is including the com.ibm.ws.security.jwt bundle. This is as designed. The configuration, though, is via the jwtConsumer element and not the openidConnectClient one. Therefore, any proposed solution is viewed from the base feature point of view, not the including one.

Please consider if configuring the same jwtBuilder configuration across the load balanced servers is an acceptable solution.

It will also be determined if providing a configurable context root for the jwt endpoint of the jwt-1.0 feature is appropriate, while it may not fully address the problem in a load balanced environment.

[bpaskin-ibm]

@teddyjtorres the jwtBuilder will not solve the issue if the token needs to be validated against an existing App Server1. App Server1 and App Server2 have completely different applications on them and different needs. App Server1 is being used as the default for validation and then allowing the token to be built and passed to App Server2, which would normally validate against App Server1. App Server2 would need to be setup to validate against the Provider, which is not something the customer wants to do. It would be better to allow turning off the context root if not being used.

[teddyjtorres]

Thank you for your help and clarifications. We will have a look and see if this is doable.

[teddyjtorres]

Thank you for bring this issue up. We will go ahead and work to provide configuration to allow changing the /jwt context root.

Regards.