IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  pkmsoidc and trimmed referer

    Posted 02/09/22 06:15 PM

    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
    ------------------------------


  • 2.  RE: pkmsoidc and trimmed referer

    Posted 02/09/22 06:39 PM

    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

     

     






  • 3.  RE: pkmsoidc and trimmed referer

    Posted 02/09/22 07:29 PM
    Edited by Sylvain Gilbert 02/09/22 07:29 PM
    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


  • 4.  RE: pkmsoidc and trimmed referer

    Posted 02/14/22 07:11 PM

    Hi - Just want to reply back on our finding of last week.

    What happens is that the URL being accessed is configured with Windows GPO to run within Edge in IE emulation mode.

    The first URL runs within Edge, and the second URL /pkmsoidc runs within an Internet Explorer sub-engine.

    The second URL, when running in Internet Explorer, does not have the "referer" http header set (lost) which then explain everything else that happens after.

    Since the /pkmsoidc is invoked with no "referer" HTTP header, WebSEAL produces a return back URL which is truncated.

    Moral of story: keep it simple and use up to date web browser software.

    Voilà !



    ------------------------------
    Sylvain Gilbert
    ------------------------------

    Original Message


Related Content