Thanks Scott. I was headed first in wrong direction but now I am have more clarity.
I am getting more valid insight now as to why with Edge our OIDC flow is broken in its way back to the OIDC RP.
Below 2 traces (Edge vs Chrome).
Removed many http headers but basically this is the request built automatically to the local OIDC RP by WebSEAL. In Edge, the "referer" header is missing. So most probably, the call to /pkmsoidc cannot locate this header and then it cannot store in memory the URL for the return trip back.
We can also see that the header "sec-fetch-site" is different.
What do you think ?
Edge:
2022-02-09-19:10:08.688-05:00I----- thread(188) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- Browser ===> PD -----------------
Thread 188; fd 260; local 1.2.3.4:443; remote 4.3.2.1:34202
GET /pkmsoidc?iss=default HTTP/1.1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
connection: keep-alive
host: app.somesite.com
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.80 Safari/537.36 Edg/98.0.1108.43
sec-fetch-site: cross-site
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Microsoft Edge";v="98"
Chrome:
2022-02-09-19:12:35.020-05:00I----- thread(147) trace.pdweb.debug:2 /build/isam/src/i4w/pdweb/webseald/ras/trace/debug_log.cpp:235: ----------------- Browser ===> PD -----------------
Thread 147; fd 260; local 1.2.3.4:443; remote 4.3.2.1:59822
GET /pkmsoidc?iss=default HTTP/1.1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
connection: keep-alive
host: app.somesite.com
referer: https://app.somesite.com/someurlparameters
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.82 Safari/537.36
sec-fetch-site: same-origin
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Google Chrome";v="98"
------------------------------
Sylvain Gilbert
------------------------------
Original Message:
Sent: Wed February 09, 2022 06:39 PM
From: Scott Exton
Subject: pkmsoidc and trimmed referer
Sylvain,
WebSEAL, when acting as a OIDC relying party, does not rely on the referrer header at all. WebSEAL will store the originally requested URL (i.e. the URL which triggered the authentication flow) in the session. I can't think of why the trimming of the referrer http header would prevent WebSEAL from redirecting the client back to the originally requested URL.
Thanks.
Scott A. Exton
Senior Software Engineer
Chief Programmer - IBM Security Verify Access
IBM Master Inventor
Original Message:
Sent: 2/9/2022 6:15:00 PM
From: Sylvain Gilbert
Subject: pkmsoidc and trimmed referer
Hi community !
About OIDC Relying Party native support in WebSEAL (and in V10 in particular) - /pkmsoidc endpoint.
Does WebSEAL (when configured to act as the OIDC Relying Party) expects the received "referer" HTTP header not to be trimmed ?
We are finding in some recent browser version that the "referer" http header (302 response from OIDC Provider back to OIDC RP WebSEAL) can be trimmed (due to increased and evolving security constraint) and does not contain any more the full URL parameters.
What is the expectation from /pkmsoidc implementation standpoint? that is to be able to properly handle redirecting to the right applications with full URLs parameter? Is the full URL cached in WebSEAL memory before transitioning from OIDC RP (WebSEAL) to OIDC Provider, or does it totally rely on the "referer" header to find its way back from a 302 ?
I am seeing unfortunately that if the "referer" http header contained in the response is trimmed out, the OIDC RP WebSEAL is not able to find its way back with the full expected URL.
https://web.dev/referrer-best-practices/
------------------------------
Sylvain Gilbert
------------------------------