Discussion Thread View
Expand all | Collapse all

PureConnect ICWS SameSite Cookies Breaks Single Sign-On

  • 1.  PureConnect ICWS SameSite Cookies Breaks Single Sign-On

    Posted 07-28-2020 10:01
    Edited by Daniel Boggs 07-28-2020 10:04
    I'm writing a client against the IC web services API (ICWS) over https. We're currently on CIC 2019 R1 Patch23.

    Single sign-on is broken in Chrome because some cookies are being set by ICWS without the SameSite attribute.

    Currently in development I'm having to set a flag when running Chrome, to hack around the issue, but that of course isn't really an option for production. We may have to resort to proxies and rewriting, but I'd like to solve it a better way.

    Is there a workaround for this in PureConnect?

    Here's what Chrome says:

    Because a cookie's SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which will prevent the cookie from being sent in a cross-site request in a future version of the browser. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.

    Resolve this issue by updating the attributes of the cookie:

    • Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
    • Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests

    And it identifies the following cookies:
    icws_<id goes here>

    I also found the following information in the PureConnect release notes. I'm guessing this is a known issue, but nothing is said about a workaround.

    Cross-site ICWS requests need samesite=none in response header

    Release : 2020r2, 2020r1 Patch 1, 2019r4 Patch 7, 2019r3 Patch 13, 2019r2 Patch 20, 2019r1 Patch 26, 2018r5 Patch 32, 2018r4 Patch 38

    Issue : IC-156993

    Issue type : Bug

    Project : IC

    Component : Session Manager

    Description : Due to chrome updating to use samesite=Lax as the default, there is a need to force "samesite=none" and "secure" in the https response header value of set-cookie if and only if this is a cross-site requst and the origin begins with https.

    Details : This is needed so that ICWS session cookies are set properly for cross-site requests. It is necessary to keep certain products (such as PC4SF) from breaking communication with the CIC server.

    Caveats and Warnings : None

    Installation Instructions : None

    Associated products: Customer Interaction Center, ICWS, Session Manager


    Daniel Boggs

  • 2.  RE: PureConnect ICWS SameSite Cookies Breaks Single Sign-On

    Posted 07-29-2020 02:54
    You cite the release notes. There it says "2019r1 Patch 26". This means that the bug is fixed in Patch 26. You wrote you are using Patch 23, so you must upgrade to Patch 26 to get the bug resolved.

    Andreas Tikart
    Fiebig GmbH

  • 3.  RE: PureConnect ICWS SameSite Cookies Breaks Single Sign-On

    Posted 07-29-2020 08:09
    Thanks. I didn't notice that detail. The readme doc isn't so clear whether this is a known issue or a fix, so I wasn't sure, but this makes sense. Thanks again.

    Daniel Boggs

  • 4.  RE: PureConnect ICWS SameSite Cookies Breaks Single Sign-On

    Posted 10-01-2020 13:23
    We've updated to 2019r1 Patch 38, but unfortunately we still see the SameSite issues when trying to authenticate with the ICWS API (using single-sign-on/ADFS and Windows Integrated); the origin is specified in the request, but the cookies coming back do not have either SameSite=None or Secure.

    We're running on Windows Server 2012 R2, and I did confirm that Windows security update KB4534309 is installed (to rule out ADFS 3.0 as being the issue). Also, the browser is running over HTTPS as well as the calls to the ICWS API.

    I wonder if this particular issue (IC-156993) has really been fixed, or whether there's something else that needs to be done to the server or CIC to get this to work.

    Daniel Boggs