Troubleshooting SSO Redirection - SameSite Cookies

Overview

Major browsers changed their cookie behavior in a way that can break third-party cookie usage, which includes both iframes and typical SSO logins with SAML and OpenID. Chrome implemented this new default behavior in August 2020. This new browser behavior handles cookies sent from the server without any defined SameSite value as SameSite=Lax, which prevents third-party access. In addition, cookies with SameSite=None must be flagged as secure; otherwise, they will be rejected. 

To resolve any issues this may cause with SSO redirection in Decisions, the server requires SSL configuration, .NET Framework 4.8, a Windows update patch, and changes to Decisions web.config files.

Before Beginning

Before diving into the resolution, confirm that Secure Cookies are enabled in the Portal Settings of the Decisions environment. To find these settings, navigate to System > Settings > Portal Settings. In the Portal Settings window, use the search bar and enter 'cookies'. This should reveal a single checkbox setting, as shown below.

Resolution

SSL, .NET Framework, and Windows

To begin, configure Secure Sockets Layer (SSL) on the Decisions server using our Configuring Server for SSL article. 

Next, download and install .NET Framework 4.8 on the server. A reboot will likely be required to complete. According to Microsoft, server-specific updates should accompany a full system update after .NET Framework 4.8 is installed. If this is not the case, install the correct .NET Framework 4.8 Windows update applicable to the server’s OS version that specifies, "ASP.NET now emits a SameSite cookie header when..." A system reboot may be necessary after installing the update. Update examples:

• "Security and Quality Rollup for .NET Framework 4.8 for Windows 8.1, RT 8.1, and Windows Server 2012 R2" - https://support.microsoft.com/en-us/help/4533004/kb4533004.
• "Cumulative Update for .NET Framework 4.8 for Windows 10 version 1607 and Windows Server 2016" - https://support.microsoft.com/en-us/help/4532997/kb4532997-cumulative-update-for-net-framework

Update Web.config File (1 of 2)

There are two web.config files that will need to be updated. The first is located at C:\Program Files\Decisions\Decisions Web Host\web.config. Open this file in a text editor, then locate the system.web element inside the configuration top-level element. There is another system.web element inside of the location element, but it is not the correct reference.

Modify the system.web element so that the sessionState element has a cookieSameSite attribute of None and the httpCookies element has a sameSite attribute of None with a requireSSL attribute of true. The code reference below is an example of how the system.web element might appear.

<system.web>
    <customErrors mode="On"/>
    <sessionState cookieSameSite="None"/>
    <httpCookies sameSite="None" requireSSL="true"/>
</system.web>

Locate the authentication section under configuration > system.web to configure the forms element. Confirm that the forms element has a cookieSameSite attribute of None and a requireSSL attribute of true—the code reference below of how the authentication element might appear.

<authentication mode="Forms">
    <forms loginUrl="Login.aspx" timeout="20160" slidingExpiration="true" path="/" name="WFAuthCookie" cookieSameSite="None" requireSSL="true"/>
</authentication>

Update Web.config File (2 of 2)

The second web.config file is located at C:\Program Files\Decisions\Decisions Web Host\HUI\web.config. Locate the authentication section under configuration > system.web to configure the forms element. Confirm that the forms element has a cookieSameSite attribute of None and a requireSSL attribute of true—the code reference below of how the authentication element might appear.

<authentication mode="Forms">
    <forms loginUrl="../Login.aspx" timeout="20160" slidingExpiration="true" path="/" name="WFAuthCookie" cookieSameSite="None" requireSSL="true"/>
</authentication>

Once these parameters have been configured as best as possible in accordance with the article, recycling the app pools should ensure that changes to the web.config files are applied.