This article describes what changes need to be done in Smart ID Digital Access component to mitigate problems and avoid downtime due to the SameSite cookie directive change.
We have now created a resolution for the full problem spectrum with the Samesite directive. As mentioned before, older browsers could not be sent the new directive due to bugs and the fact that the unimplemented feature sometimes breaks current functionality. This has now been resolved with a configuration file placed on the Access Point which will identify the problematic browsers and act accordingly in these cases. The fact that this is a configurable file makes it possible to adapt to future discoveries of the same sort without needing to replace the binaries again.
Note that the first hotfix which was made available on February 11th does not have this full functionality and if applied already it must be replaced with the below version.
In May 2019, Google announced improved cookie security and handling in this draft. The changes proposed in this draft will be adopted into major browsers in February 2020. It is not in the context of this article to describe the reasoning, causes and general effects of this change so please take the time to read this post on the subject. This modification will affect a vast number of systems on the internet and it is likely that many services will have decreased functionality during a period following this change.
Update 2020-04-28: In Safari, on the latest version of iOS (13.4.1), Apple released an update regarding privacy. The browser will now block all third-party cookies, independent from the SameSite configuration.
The changes by Chrome were initially scheduled for update 80 scheduled for the 4th of February 2020 but the release has been pushed forward to a small subset on the 17th of February. It is therefore not currently known when the changes will be incorporated in larger proportion of the user base, but it is recommended that the described fix is applied as soon as possible to avoid any downtime or negative user experience.
Implications for Digital Access component
Digital Access component uses two cookies to keep track of the user session: WAAK, which is marked as secure (will only be delivered in an SSL context) and WASID, which is not marked as secure (to be able to track the session over non-SSL contexts).
One of the changes mentioned above is that cookies which are NOT marked as secure will no longer be delivered in an SSL third-party context. This means that the WASID cookie will not have full functionality as before.
In a basic Digital Access component installation, this it not a concern as the user will stay in a first-party context during the entire session. There are however other use cases that will be affected.
Examples of affected use cases:
- When Digital Access component is embedded in an iframe or similar under a different domain than the main site.
- SAML federation, when the user will be transported to a different domain for authentication, which will trigger third-party cookie handling.
Available solution: hotfix
The solution, which will fit most contexts, is to start setting the secure flag for the WASID cookie as well as defining it as
SameSite=none. This solution will be provided as a hotfix for the Access Point and the process to apply it is quick. For information on the available versions and checksums, see the table below.
Apply hotfix - Step-by-step instruction
The steps to apply the fix are as follow:
Log in with your Nexus support account to Nexus' Support Portal via this link: Download Samesite hotfix - HAG-1858.
- Select your current version of Digital Access component, and download the .zip file. For information on the available versions and checksums, see the table below.
- Copy the new binary from the .zip file to the appliance, for example by using the secure copy (scp) command. Also copy the supplied configuration file Samesite.conf to the appliance using the same method.
- Connect via secure shell (ssh) to the Digital Access component appliance.
Elevate the prompt:
Example: Elevate the promptCODE
sudo su -
Verify that this system is running a General Available release:
Run the following command:
Example: Verify General AvailabilityCODE
This command will display something like this:
Name: Access PointVersion: Release 5.13.4, (build 301 - 20191112)
301is the build number.
- Verify that the build number is a three digit number.
If it's a four digit number it means that this Access Point is already running a different hotfix which will be removed if the new hotfix is applied. If that is the case, contact Nexus support for instructions on how to proceed. See the Contact section below.
Stop the Access Point:
Example: Stop the access pointCODE
Make a backup of the original Access Point file:
Example: Make backup of the original fileCODE
cp /opt/nexus/access-point/bin/access-point ~/access-point.old
Replace the file. This example assumes that the new binary is available in
Example: Replace the fileCODE
cp ~/access-point /opt/nexus/access-point/bin/access-point
Add the configuration file.
This example assumes that the new file is available in
Example: Copy fileCODE
cp ~/access-point /opt/nexus/access-point/config/samesite.confFile content: samesite.confCODE
\(iP.+; CPU .*OS 12[_\d]*.*\) AppleWebKit\/:exclude \(Macintosh;.*Mac OS X 10_14[_\d]*.*\) AppleWebKit\/:exclude Chrome\/5[1-9].[0-9]*:exclude Chrome\/6[1-6].[0-9]*:exclude UCBrowser\/12\.13\.[0-1].*:exclude UCBrowser\/12\.1[0-2]\.[0-9].*:exclude default:none
Modify file permissions:
Example: Modify file permissionsCODE
chown pwuser:pwuser /opt/nexus/access-point/config/samesite.conf
Start the Access point:
Example: Start the access pointCODE
- Verify in the developer tools of any browser that both the WAAK and WASID cookies are set with the
The fix is available for the following Digital Access component versions:
|Version of Digital Access component
|Path to .zip file
|SHA 256 checksum
Please address any questions about the fix and how to apply it to email@example.com.
You need to have a Nexus support account to access this site.