Hi Thomas,
The OIDC TAI uses its OIDC session cookie to determine if the user is logged in. The cookie must exist and the value for the cookie must exist in its session cache. If the OIDC TAI writes the cookie for one request, but is unable to read the cookie for the next request, from its point of view, the user is not logged in and will be redirected to the OP.
The biggest reason why the TAI would not be able to read its session cookie is a samesite issue. I can give you instructions for reading the trace to confirm that the missing cookie is the issue (as opposed to the value for the cookie missing from the cache). I've found that the easiest way to figure out if this is the problem is to set the property and retry.
To check the trace, you can look for these statements in the trace:
1) No Relying party session cookie found in the request
2) CWTAI2009I: The OpenID Connect relying party (RP) did not find an entry for session cookie {0} in the Session cache.
Note that you will always get the
No Relying party session cookie found in the request on the initial login.
If, on the run through the AuthenticateUsingSessionCookie method for the 2nd request that you expect to work and you get one of those messages, (1) is most likely a samesite issue and (2) is the session being removed from the cache for some reason, or it was never there in the first place (like the 2nd request went to a different server, so it is a different cache, however, you wouldn't see the 1st and 2nd request in the same trace in this case.)
------------------------------
Barbara Jensen
------------------------------
Original Message:
Sent: Wed July 13, 2022 07:43 AM
From: Thomas Mayr
Subject: OpenID Cookie expected by WebSphere RP
Hi Barbara,
I was not aware, that it is the job of the authorize endpoint in my application to check if the user is already logged-in. I can see, that the JSESSION cookie is there and I have to check my application, why it doens't recognize that the user is still logged-in.
Yes we are making progress with a slightly differnt setup. We had to use ForgeRock OpenAM as OP instead of Liberty. This was a cistomer requirement.
But we are still struggeling with session handling between our two applications (global logout and session timeout). IMHO the RP should handle this, but it doesn't do so.
Kind regards
Thomas
------------------------------
Thomas Mayr
------------------------------
Original Message:
Sent: Wed July 13, 2022 07:32 AM
From: Barbara Jensen
Subject: OpenID Cookie expected by WebSphere RP
Hi Thomas,
Good to hear from you too. I'm glad that you're making progress on your project.
It could be a samesite issue. I ran into this when I was working on a test system a few days ago. Try setting this custom property in the Global security custom properties:
com.ibm.websphere.security.addSameSiteAttributeToCookie=Lax
Here's the path to set the property:
Security > Global security > Custom properties > New
Restart the server, then retest
------------------------------
Barbara Jensen
Original Message:
Sent: Wed July 13, 2022 07:24 AM
From: Thomas Mayr
Subject: OpenID Cookie expected by WebSphere RP
Hello Barbara,
nice to here you again! We have only one provider entry in the RP configuration.
Kind regards
Thomas
------------------------------
Thomas Mayr
Original Message:
Sent: Wed July 13, 2022 06:39 AM
From: Barbara Jensen
Subject: OpenID Cookie expected by WebSphere RP
Hi Thomas,
The OIDC RP can have more than one session cookie. How many provider entries do you have in your WebSphere OIDC TAI config? If there is more than one, are the requests that are being sent to the OP for login independently being serviced by filters in different provider configs?
By 'provider entries/configs', I mean provider_1.something, provider_2.something, etc.
------------------------------
Barbara Jensen