Starting with the Collaborative Lifecycle Management Solution 6.0 software release, Jazz Security Architecture SSO is available as an authentication option. Based on OpenID Connect , authentication is NOT performed by the container hosting Jazz applications, but instead is delegated to a separate Jazz Authorization Server (JAS), which performs the role of an OpenID Connect provider (OP).
For further Information on Jazz Security Architecture you can visit our jazz.net article Jazz Server Authentication Explained
You can configure the Liberty OpenID Connect Provider to further delegate the user authentication to your standard, corporate OpenID Connect provider using the Liberty "Social Login" feature. Using this method we can delegate authentication from JAS to another OIDC provider. This is the focus of the article.
The configuration information are extracted and modified for JAS from Liberty Topic: Configuring Social Login in Liberty
The following diagram depicts the deployment topology and the authentication flow.
Overview of the different steps involved in this configuration.
Although the authentication is redirected and performed by the Third Party OIDC Provider, JAS and ELM still needs to connect to the LDAP server for User-to-group role mapping (JazzAdmins, JazzUsers and so on) and JAS as well needs to be configured with the same LDAP server for ID Token and Application Passwords mapping. Most customers don't expose the LDAP server working with the Third Party OIDC Provider and instead create a replica with limited attributes and passwords disabled.
As a pre-req , first configure JAS with the LDAP server and then setup ELM Configure JAS with LDAP
The default certificate generated is a self-signed certificate for common Name localhost
. While this works for JAS and ELM with warnings, it would fail when configuring with another OIDC Provider. You would need to generate a CA certificate for JAS where CA is your Enterprise Certificate provider.
You could also generate an updated Self-Signed certificate with Common Name matching your JAS URL. You would then need to import the new certificate generated for JAS to the truststore of your OIDC Server and also import the certificate from discovery endpoint into JAS truststore.
By default the Social Login configuration uses the RS256 signature algorithm.
You can configure a Liberty server so that users can authenticate to websites that are hosted on the Liberty server by logging in with their social media accounts. For JAS to connect to a different OIDC server we define our own social login configuration that is based on the OAuth 2.0 or OpenID Connect 1.0 standards.
In Liberty, social login is enabled by the socialLogin-1.0 feature. Here are instructions to configure Social Login for a 3rd Party OIDC server.
[JAS_HOME]\wlp\usr\servers\jazzop\server.xml
configuration file and add the socialLogin-1.0 , ssl-1.0 and appSecurity-2.0 features.
<featureManager> <feature>socialLogin-1.0</feature> <feature>appSecurity-2.0</feature> <feature>ssl-1.0</feature> ... </featureManager>
oidcLogin
element and configure the connection to your OIDC provider
authorizationEndpoint
, tokenEndpoint
, jwksUri
and issuer
attributes
https://accounts.google.com/.well-known/openid-configuration
[JAS_HOME]\wlp\usr\servers\jazzop\appConfig.xml
after oauthProvider
section
<oidcLogin id="myoidcserver" displayName="OIDC Login" clientId="[my_client_Id]" clientSecret="[my_client_password]" authorizationEndpoint="https://accounts.google.com/o/oauth2/v2/auth" tokenEndpoint="https://www.googleapis.com/oauth2/v4/token" jwksUri="https://www.googleapis.com/oauth2/v3/certs" issuer="https://accounts.google.com" scope="openid profile email" userNameAttribute="email" mapToUserRegistry="true" > </oidcLogin>
clientId
and clientSecret
are to be generated by your OIDC provider (In the next step)
https://liberty_host:SSL_port/ibm/api/social-login/redirect/oidclogin_id
https://[JAS_HOST]:[Port]/ibm/api/social-login/redirect/myoidcserver
Create an application for JAS in your corporate OIDC provider and register the server with the application by providing a redirect URL of JAS as mentioned in the previous step.
For example, the redirect URL for the oidcLogin configuration example has the following format:
https://[JAS_Host]:[Port]/ibm/api/social-login/redirect/myoidcserver
After you create the application, note the Client ID and Client Secret. Update them in the JAS configuration created in step 3, the attributes to be updated are clientId="[my_client_Id]"
and clientSecret="[my_client_password]"
Starting version 7.0.2 you can configure Application Passwords for Non-Web Clients. The filters are different when JAS is configured with App passwords.
In 7.0.1 and below, The OIDC authentication flow works for Web Clients only. We need to add a filter to redirect only the browser based clients to the 3rd party OIDC server. This way the Thick clients like Eclipse, VS and command line utilities would directly authenticate with the underlying LDAP configured with JAS.
The filter configuration is as follows:
<authFilter id="myoidcAuthFilter"> <userAgent id="oidcUserAgent" agent="Mozilla|Opera" matchType="contains"/> <requestUrl id="oidcRequestUrl" urlPattern="/authorize" matchType="contains" /> </authFilter>
<oidcLogin id="myoidcserver" displayName="OIDC Login" clientId="[my_client_Id]" clientSecret="[my_client_password]" authorizationEndpoint="https://accounts.google.com/o/oauth2/v2/auth" tokenEndpoint="https://www.googleapis.com/oauth2/v4/token" jwksUri="https://www.googleapis.com/oauth2/v3/certs" issuer="https://accounts.google.com" scope="openid profile email" userNameAttribute="email" mapToUserRegistry="true" authFilterRef="myoidcAuthFilter" > </oidcLogin> <authFilter id="myoidcAuthFilter"> <userAgent id="oidcUserAgent" agent="Mozilla|Opera" matchType="contains"/> <requestUrl id="oidcRequestUrl" urlPattern="/authorize" matchType="contains"/> </authFilter>
With ELM authentication is configured with a Third Party OIDC Provider, the Logout operations from ELM does not complete.
We have documented a Workaround (link below) where ELM uses a custom Web Logout URI. This workaround would work if you can directly access to the OIDC Logout URL.
Configure Logout for ELM when configured with Third Party OIDC Provider
Status icon key: