If you are implementing or upgrading your workload scheduler product, you will probably be asked a question about user repositories, specially if the company is adopting hyperscalers there will be a push to adopt identity management services such as Okta, Auth0, Ping, Microsoft Entra ID, SiteMinder and others.
Which begs the question, does IBM/HCL workload automation supports these identity management services? The answer is yes, via OpenID Connect Protocol!
In this tutorial we will demystify OpenID, oauth2, JWT concepts, how they play together and integrate with DWC/MDM, we will go into step by step and use okta as an OpenID provider and show the implementation from okta’s side as well.
So, what is Oauth2, OpenID Connect (OIDC), and JWT?
OAuth 2.0 is an open standard for web authorization, it allows logging into 3rd party sites using social network.
OIDC is a protocol built on top of the OAuth 2.0 framework. It allows third-party applications to confirm its id to a relying party, by doing so, those users will be authenticated.
Json Web tokens (JWT) represents the claims to be exchanged between two parties. Claims are statements (like name, email and groups) about an entity (usually, the user).
With that in mind, we will start to define the grounds for our integration, note DWC / MDM’s WebSphere/open liberty will act as OpenID Connect Clients, hence we need an OpenID Connect Provider to act as identity provider, this is where the identity management services, I mentioned on the beginning comes in.
Figure 1 shows the the OpenID flow, it starts by the user accessing DWC’s login page, WAS/OpenLiberty will re-direct to our 3rd party OIDC provider(Okta in this case) which will ask for the user to login, once logged DWC’s WAS/Openliberty will construct the JWT based on the claims from Okta and if user has access it will granted. Our DWC will also build/propagate JWT to our MDM’s WAS/OpenLiberty, by doing so we will establish the single sign-on between DWC and MDM.
In this tutorial we will demystify OpenID, oauth2, JWT concepts, how they play together and integrate with DWC/MDM, we will go into step by step and use okta as an OpenID provider and show the implementation from okta’s side as well.
So, what is Oauth2, OpenID Connect (OIDC), and JWT?
OAuth 2.0 is an open standard for web authorization, it allows logging into 3rd party sites using social network.
OIDC is a protocol built on top of the OAuth 2.0 framework. It allows third-party applications to confirm its id to a relying party, by doing so, those users will be authenticated.
Json Web tokens (JWT) represents the claims to be exchanged between two parties. Claims are statements (like name, email and groups) about an entity (usually, the user).
With that in mind, we will start to define the grounds for our integration, note DWC / MDM’s WebSphere/open liberty will act as OpenID Connect Clients, hence we need an OpenID Connect Provider to act as identity provider, this is where the identity management services, I mentioned on the beginning comes in.
Figure 1 shows the the OpenID flow, it starts by the user accessing DWC’s login page, WAS/OpenLiberty will re-direct to our 3rd party OIDC provider(Okta in this case) which will ask for the user to login, once logged DWC’s WAS/Openliberty will construct the JWT based on the claims from Okta and if user has access it will granted. Our DWC will also build/propagate JWT to our MDM’s WAS/OpenLiberty, by doing so we will establish the single sign-on between DWC and MDM.
Pre-requirements (OpenID connect 3rd part provider – Okta)
As stated above, we need an OpenID Client Provider ready to accept requests, Figure 2 showcase an Okta’s application that we will use through-out this configuration.
As stated above, we need an OpenID Client Provider ready to accept requests, Figure 2 showcase an Okta’s application that we will use through-out this configuration.
Let’s make note of the client ID and client Secret for us to start configuring our DWC’s WebSphere/OpenLiberty.
Also, we need to request a Okta administrator to add our sign-in redirect URI(Uniform Resource Identifier), (aka reply URL). Okta sends the authentication response and ID token for the user's signin request to these URLs, which in this case is DWC’s URL.
On top of my newly created application, I will add an Okta’s Authorization server, which will define my security boundaries and it’s where I can de fine custom claims, access policies etc.
Make a note of metadata URL (Metadata Object Identifier) which will be used by WebSphere/OpenLiberty to retrieve the configuration from it.
Make a note of metadata URL (Metadata Object Identifier) which will be used by WebSphere/OpenLiberty to retrieve the configuration from it.
DWC OpenID Connect configuration.
With the OIDC provider information in hands we will start configuring DWC, the official documentation here, mentions the template file we will use to start our configuration.
Config 1 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 the entire description on what they mean, make sure to review openliberty documentation here.
Below is the description of the main properties:
userIdentifier = this is the attribute my login will look like. (I choose the email address).
groupIdentifier= this is the claim that will contain all the groups the user belongs to (this is crucial as I will use those groups to map the roles on DWC as well as MDM).
redirectToRPHostAndPort = After authenticating this is the URL the user will be redirected to.
mapIdentityToRegistryUser ="false" it tells WAS/OpenLiberty to not check the registry (LDAP) for any users that are logging in using the OIDC configuration.
Notice I’ve also added an authFilter block, this is important because I am excluding from my authorization all the urls that contains those names on it.
Them I will tell OpenLiberty to follow that Filter during authentication by using authFilterRef=”restFilter”.
This is a nice to have as for example If I wanted to login to DWC using my local OpenLiberty account to troubleshoot I would simply enter the URL as https://hwa-demo.hclpnp.com/console/login.jsp, hence OpenLiberty would not use OIDC.
With the OIDC provider information in hands we will start configuring DWC, the official documentation here, mentions the template file we will use to start our configuration.
Config 1 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 the entire description on what they mean, make sure to review openliberty documentation here.
Below is the description of the main properties:
userIdentifier = this is the attribute my login will look like. (I choose the email address).
groupIdentifier= this is the claim that will contain all the groups the user belongs to (this is crucial as I will use those groups to map the roles on DWC as well as MDM).
redirectToRPHostAndPort = After authenticating this is the URL the user will be redirected to.
mapIdentityToRegistryUser ="false" it tells WAS/OpenLiberty to not check the registry (LDAP) for any users that are logging in using the OIDC configuration.
Notice I’ve also added an authFilter block, this is important because I am excluding from my authorization all the urls that contains those names on it.
Them I will tell OpenLiberty to follow that Filter during authentication by using authFilterRef=”restFilter”.
This is a nice to have as for example If I wanted to login to DWC using my local OpenLiberty account to troubleshoot I would simply enter the URL as https://hwa-demo.hclpnp.com/console/login.jsp, hence OpenLiberty would not use OIDC.
With this configuration loaded (you can name openid_authentication.xml under overrides folder), I should be able to login to DWC with URL https://dwchostname.com which will take me to okta’ s authentication page.
If I have not defined the groups coming from okta, DWC will return a message saying no roles is assigned to my id. So, make sure you have the groups defined under Administration > Manage roles.
If I have not defined the groups coming from okta, DWC will return a message saying no roles is assigned to my id. So, make sure you have the groups defined under Administration > Manage roles.
Figure 7 shows group Non-SoFy@Users been added to DWC rules Administrator.
Single Sign-on DWC / MDM
With DWC configured with OIDC, my MDM’ s WAS/OpenLiberty is not aware of it. Therefore I will 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 I added on DWC’s overrides folder.
Config 2 code block shows jwt_sso_mdm.xml which in turn I added on MDM’s overrides folder. With it, the MDM will be able to process the token coming from DWC, hence we will be able to use the username and group to authenticate on conman / composer as well as the engine.
With DWC configured with OIDC, my MDM’ s WAS/OpenLiberty is not aware of it. Therefore I will 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 I added on DWC’s overrides folder.
Config 2 code block shows jwt_sso_mdm.xml which in turn I added on MDM’s overrides folder. With it, the MDM will be able to process the token coming from DWC, hence we will be able to use the username and group to authenticate on conman / composer as well as the engine.
As MDM’ s WAS/OpenLiberty is aware of the JWT token, I will add my OIDC group “Non-SoFy@Users” to MDM’ s security file / acl.
As MDM’ s WAS/OpenLiberty is aware of the JWT token, I will add my OIDC group “Non-SoFy@Users” to MDM’ s security file / acl.
To make sure Single Sign On is working, I will go ahead and create a engine connection pointing to my MDM, without credentials (Figure 9), notice I am able to access Orchestration Monitor without been asked for username and password (figure 10).
Finally if I inspect my DWC cookies (Press f12 on your browser to open developer tools) I will notice wajwt cookie been set (Figure 11).
Copy and paste the string on jwt.io to visualize the contents of the cookie (Figure 12), it’ s very handy to troubleshoot how my cookie is been generated, as well as to make sure the groups I needed are been passed on within the cookie.
That concludes our OIDC journey on MDM / DWC WAS/OpenLiberty, feel free to reach me out at juscelino.candi@hcl.software for any questions related to OIDC on IBM / HCL Workload Automation!!
| Authors | |
 | Juscelino Candido De Lima Junior Juscelino has over 15 years in the IT industry, at IBM, he started as an IT Specialist - Workload Automation, in the last five years working as an infrastructure and application IT architect. His areas of expertise include multi-cloud architecture, containers, microservices, observability, virtualization, networks, distributed systems, systems administration, production control, and enterprise job scheduling. IBM Master Inventor with +20 filed patents. |
 | Davide Malpassine Davide joined HCL in September 2019 as the Technical Lead working on the IBM Workload Automation product suite. He has 14 years of experience in software development and was tasked with the extension of the Workload Automation product from a Kubernetes native environment to the Red Hat OpenShift Container Platform, and the REST API for the Workload Automation engine. He has a Master’s Degree in Computer Engineering. |