Demystifying OpenID Connect, OAuth 2, and JWTs on HWA

If you are implementing or upgrading your workload scheduler product, you will probably be asked about user repositories. If the company is adopting hyperscalers, in particular, there will be a push to adopt identity management services such as Okta, Auth0, Ping, Microsoft Entra ID, or SiteMinder.

Which leads to a question: Does IBM/HCL Workload Automation support these identity management services? The answer is yes — they’re supported using the OpenID Connect protocol.

In this tutorial, we'll demystify OpenID Connect (OIDC), OAuth 2.0 and JSON Web Token (JWT) concepts and examine how they play together and integrate with DWC/MDM (Dynamic Workload Console/Master Domain Manager). We'll discuss using Okta as an OpenID provider step by step and show the implementation from the Okta side as well.

What are OAuth 2, OpenID Connect (OIDC) and JWT?

Let’s start with a few definitions:

• OAuth 2.0 is an open standard (“OAuth” is short for “open authorization”) that aims to standardize the process for authenticating and authorizing users signing in to access digital services. It enables users to log in to third-party sites using social networks.
• OpenID Connect (OIDC) is an identity authentication protocol built on and extending the OAuth 2.0 framework, which enables users to log in to third-party applications with a single user ID.
• JSON Web Tokens (JWTs) represent the claims to be exchanged between two parties. Claims are statements (such as name, email and groups) about an entity (usually the user).

With all that in mind, we'll start to define the basis for our integration. Note that MDM/DWC WebSphere Liberty/Open Liberty will act as OIDC clients, which means we need an OIDC provider to act as identity provider. This is where the identity management services we mentioned at the beginning of this post come in.

Figure 1 shows the the OpenID flow.

1. The flow starts with the user accessing DWC’s login page.
2. WAS/Open Liberty redirects the user to a third-party OIDC provider, such as Okta.
3. The third-party OIDC provider prompts the user to log in and the user submits credentials.
4. The third-party OIDC provider authenticates the user.
5. DWC’s WAS/Open Liberty constructs the JWT based on the claims from Okta. If the user has access privileges, resource access will be granted.
6. DWC propagates the JWT to MDM’s WAS/Open Liberty, establishing the single sign-on between DWC and MDM.
7. DWC sends resources to the user.

Figure 1 HWA x OpenID authorization flow

Prerequisites (OpenID Connect Third-party Provider – Okta)

As noted above, we need an OpenID client provider ready to accept requests. Figure 2 shows an Okta application which we will use throughout this configuration.

Figure 2 Okta's OpenID Connect application

Let’s take note of the client ID and client secret to start configuring our DWC’s WebSphere Liberty/Open Liberty.

Figure 3 Okta's client / secret

We also need to request that an Okta administrator add our sign-in redirect URI (Uniform Resource Identifier, otherwise known as a reply URL). Okta sends the authentication response and ID token for the user's sign-in request to these URLs, which in this case is DWC’s URL.

Figure 4 Okta sign-in redirect URI

On top of our newly created application, we’ll add an Okta authorization server, which will define our security boundaries and enable us to define custom claims, access policies, and so on.

Note the metadata URI (Metadata Object Identifier) which will be used by WebSphere Liberty/Open Liberty to retrieve the configuration.

Figure 5 Okta authorization server

DWC OpenID Connect Configuration

With the OIDC provider information in hand, we'll start configuring DWC. The official documentation here mentions the template file we'll use to start our configuration.

Config 1 (below) shows the file already filled out with our ClientID, ClientSecret and discoveryEndpointURL (our metadata URI).

Each option can be customized to reflect your OIDC provider configuration. For a complete explanation of what they mean, review the Open Liberty documentation here.

Below is a description of the main properties:

userIdentifier = The attribute my login will look like (we choose email address).

groupIdentifier = This is the claim that will contain all the groups the user belongs to. This is crucial, as we will use these groups to map the roles on DWC as well as MDM.

redirectToRPHostAndPort = After authenticating, this is the URL to which the user will be redirected.

mapIdentityToRegistryUser = "false" This tells WAS/Open Liberty not to check the registry (LDAP) for any users that are logging in using the OIDC configuration.

Notice that we’ve also added an authFilter block. This is important because we’re excluding from authorization all URLs containing those names.

We then tell Open Liberty to follow that filter during authentication by using authFilterRef=”restFilter”

This is a nice-to-have. For example, if I want to log in to DWC using my local Open Liberty account in order to troubleshoot, I simply enter the URL as https://hwa-demo.hclpnp.com/console/login.jsp so that OpenLiberty won’t use OIDC.

Config 1 OpenID authentication (initial)

With this configuration loaded (you can name openid_authentication.xml under overrides folder), I should be able to log in to DWC with the URL https://dwchostname.com, which will take me to the Okta authentication page.

If I have not defined the groups coming from Okta, DWC will return a message saying no roles are assigned to my ID. So make sure you have the groups defined under Administration > Manage roles.

Figure 6 DWC Manage roles

Figure 7 shows group Non-SoFy@Users been added to DWC rules Administrator.

Figure 7 Add OIDC group

Single Sign-On DWC/MDM

With DWC configured with OIDC, our MDM’s WAS/Open Liberty is not aware of it. We therefore add jwtSso-1.0 to have information about configuring JWT Single Sign-On as well as mpJwt-1.1 to create a configuration to process the MicroProfile JWT token.

Config 2 code block shows the file jwt_sso_dwc.xml that we added to DWC’s overrides folder.

Config 2 code block shows jwt_sso_mdm.xml, which was in turn added to MDM’s overrides folder. With it, the MDM will be able to process the token coming from DWC. We thus will be able to use the username and group to authenticate on conman/composer as well as the engine.

Config 2 jwt_sso_dwc.xml

Figure 8 MDM jwtsso_mdm.xml

As MDM’s WAS/Open Liberty is aware of the JWT token, we'll add the OIDC group “Non-SoFy@Users” to MDM's security file/acl.

Config 3 MDM acl with OIDC group

To make sure Single Sign-On is working, we'll go ahead and create an engine connection pointing to my MDM, without credentials (Figure 9). Note that we’re able to access Orchestration Monitor without being asked for a username and password (Figure 10).

Figure 9 MDM engine without credentials

Figure 10 Orchestration Monitor UI

Finally, if we inspect our DWC cookies (Press F12 on your browser to open developer tools) we’ll notice that the wajwt cookie has been set (Figure 11).

Figure 11 DWC wajwt cookie

Copy and paste the string on jwt.io to visualize the contents of the cookie (Figure 12). It’s very handy to troubleshoot how our cookie has been generated, as well as to make sure the groups we needed are being passed on within the cookie.

Figure 12 DWC wajwt token

That concludes our OIDC journey on MDM/DWC WAS/Open Liberty. Feel free to reach out to me at juscelino.candi@hcl.software for any questions related to OIDC on IBM/HCL Workload Automation.