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
Original Message:
Sent: Wed July 06, 2022 03:33 AM
From: Thomas Mayr
Subject: OpenID Cookie expected by WebSphere RP
Hello IBM Folks,
we have two WEB applications, one deployed on a traditional WebSphere 9 (WSPAPP) and one on SAP WAS (SAPAPP) participation in a SSO scenarion using Open ID Connect. The OpenID provieder (OP) is OpenAM (ForgeRock). On WebSphere a relying party interceptor (RP) is configured and the communication between the RP and OP is working. The WSPAPP provides the login page and the OpenID authorize endpoint, which calls the authorize endpoint of the OP after the user has been logged in.
The problem is now, when an authorized user navigates from the SAPAPP to a protected page of the WSPAPP, the WebSphere RP doesn't recognize, that the user is already logged in and the user agent is redirected to the login page.
The follwing steps are executed in this scenario:
- An unauthorized user navigates to a protected page of the SAPAPP
- The SAP WAS redirects the user agent to the authorize endpoint of the WSPAPP (passing the redirect URI, and the other parameters)
- The WSPAPP redirects the user agent to the login page
- After a successful login the WSPAPP calls the authorize endpoint of the OP to get the authorization code
- The WSPAPP redirects the user agent is redirected to the redirect URI with the authorization code
- The SAP WAS gets the OpenID tokens from the OP and redirectst the user agent to the protected page of the SAPAPP
- SO FAR SO GOOD
- Now the user navigates from the SAPAPP to a protected page of the WSPAPP
- And now the WebSphere RP doesn't recognize, that the user is already authorized and calls the authorize andpoint of the WSPAPP
So the question is, which cookies does the WebSphere RP expect to recognize that the user is authorized?
When the user first navigates to a protected page of the WSPAPP, the WebSphere RP sets some OIDC and Ltpa2 cookies. Then the naviagetion betwen the two applications works as expected.
Kind regards
Thomas
------------------------------
Thomas Mayr
------------------------------