Multiple Liberty servers SSO with OpenId Connect

Question

I am trying to use openidconnect plugin to achive SSO between multiple Liberty servers. Using Keycloak as openid provider and configuration is like this.

<webAppSecurity  logoutOnHttpSessionExpire="true"  ssoCookieName="LtpaToken2" />
<openidConnectClient id="RP" scope="openid" signatureAlgorithm="RS256"
    clientId="liberty" clientSecret="secret"
    discoveryEndpointUrl="https://localhost:8243/auth/realms/abc/.well-known/openid-configuration"
    userIdentityToCreateSubject="id"
    groupIdentifier="groupof"
    realmName="abc"
    />
<application type="ear" location="/opt/was-services.ear"></application>

These are the things happening with one server

1. Upon protected resource https://localhost:9444/test-services/secure/whoAmI access it is redirecting me to Keycloak to login
2. After successful login with keycloak it redirected me back to Liberty server https://localhost:9444/oidcclient/redirect/RP with code and state
3. (Internal) Openid plugin called keycloak to fetch accessToken & idToken with code and created subject and redirected me back to https://localhost:9444/test-services/secure/whoAmI with cookie WASOidcCode (only one cookie)
4. Once browser redirected to whoAmI endpoint then it got success response with below cookies

Set-Cookie: WASOidcCode=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASOidcStaten1705148370=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASOidcStaten1705148370=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASOidcState=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASReqURLOidc=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASOidcCode=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASOidcNonce=""; Expires=Thu, 01 Dec 1994 16:00:00 GMT; Path=/; HttpOnly
Set-Cookie: WASOidcClient_p2088384039=viftWG2c2OLfstAJs20olB1ik6sqt0AN; Path=/; HttpOnly
Set-Cookie: WAS_p1727417709=EdONwO1su3sXZp3OFPlbu7lsbwmUF5GKbAdQswzuKQE9oA/If0pLRO4T5owRXm+3c7W+LEHNmDGFBisCe14enxnZPMuM2sTO/gTy+RT10gUVDC5r++HR3UHBLov7GmBPrmwTK8ISMZnSEgMxMr7RLTUi917dlBVEQ9ga14gN8PuaUA0lW+h1i/Ya870qZ+HvjoH6EDnwKmGFC9j8Ba1Unkr8FWRO4JUy8VVzJX5NNT/fmbns2CXnB69ICMk9gMC4YaYpJ1LRzfn22iv9404Vq0qy8lwEeQTQx/urz8bu6qI930+eJI0KqP3O2Kv434p6bdexg5eNdvIYKw9Ldz4J96SHrjCQOHVuYt6hzfHUg9DT8QIrQizznbZU2D8xKe3TDfeqActgK044AkBA+88K7sRMScbxnTAeggjZqYHrDjIe/8MlBcmfAxsYr0t5yzHj/QaQlJzh16xmzVS2+FdMlQ==; Path=/; HttpOnly

But when I go to another liberty server (assume https://localhost:9544/test-services/secure/whoAmI) same redirects happened in the background (with out OP login as I already logged it), but I got another WAS cookie this time with different name WAS_p1737373709.

Question

1. Are these WAS_xxxxx cookie is like LtpaToken2?
2. Why 2 servers given 2 different cookies
3. Can we avoid these OP redirects while moving between different servers (can we store the customer details in cookies or somewhere)?
4. How AJAX call works, assume like i logged in into SeverA, but making AJAX call to ServerB.
5. If every server need the code to introspect (in authorisation code flow), do we need to expose the each server oidcclient endpoint?
6. How to logout from all servers? Do we have a single logout endpoint?

How can I understand this OIDC implementation in Liberty?

Answer 1

Here's an attempt at explanation -

Q1) Are these WAS_xxxxx cookie is like LtpaToken2 ?

A1) Yes.

Q2) Why two different cookies?

A2) When two different servers issue a cookie of the same name, the 2nd one replaces the first, then the user would get an unexpected authentication challenge when they went back to the first server. The use of different names avoids this problem, but it also prevents transparently load-balancing across multiple identical servers without a trip back to the provider.

Q6) Do we have a single logout endpoint ?

A6) OIDC does not have distributed logout, but SAML does. However when a shared cookie is used, the effect of server "a" deleting the cookie would also block access to server b, c, d, etc.

Q3) Can we avoid these OP redirects while moving between different servers (can we store the customer details in cookies or somewhere )?

A3) Yes, although a different kind of cookie needs to be used. LTPA cookies don't hold full information about users, the server has to call back to the user registry (such as LDAP) to get it. But when using a remote identity provider such as OIDC, that is not possible. The LTPA cookie can be replaced with a JWT cookie by adding the jwtsso-1.0 feature. Then sharing a cookie across servers without going back to the provider becomes possible.

Q4) How AJAX call works, assume like i logged in into SeverA, but making AJAX call to ServerB.

A4) Once #3 is done, #4 becomes possible, but the servers' CORS settings might need tuning.

Q5) Do we need to expose the each server oidcclient endpoint ?

A5) Using a JWT cookie should be self contained in most cases once you have it, but all clients still need to be able to communicate with the provider in case they are the one that starts the login process.

To implement #3 use Liberty 20.004 or higher, add this feature:

<feature>jwtsso-1.0</feature>

and add this attribute to the openIdConnectClient xml element:

includeCustomCacheKeyInSubject="false"

If the servers are not completely identical (i.e. Docker containers) then you'll need a little more customization so they build identical jwt's despite having different hostnames and/or ports:

<jwtSso jwtBuilderRef="myBuilder" />
<jwtBuilder id="myBuilder" issuer="https://localhost:9443/jwt"
    jwkEnabled="false" />

  <mpJwt id="myMpJwt" issuer="https://localhost:9443/jwt" />

You'll see a new cookie called JWT.

To work between multiple servers, their keystore (used to sign the JWT) and truststore (used to read it) must be configured the same. Sharing the same key.p12 file across all servers is one way to do this.

I hope this is helpful.