Problem

Users receive an error during SSO stating "The account ... is not authorized to access this application".

Quick Navigation

• How do I know if I am affected by the SameSite cookie issue?
• Solution

How do I know if I am affected by the SameSite cookie issue?

How and when the SameSite cookie affects users is dictated by a number of factors.  The most common causes are listed here for reference:

• Your PortalGuard server has a recent Windows Update installed:
  • Microsoft SameSite KB List
• Chrome version 80 or later (Release Date: February 4th, 2020) is used as the browser.
  • Chrome is the biggest proponent for pushing this change into the current internet space and has various sources for more information.  For a concise overview of the SameSite cookie, visit the Chromium Blog:

    • Get Ready for New SameSite=None; Secure Cookie Settings

• The error only appears during SP-Initiated SSO where a POST is made to the '/sso/go.ashx' endpoint.
  • e.g. when attempting SSO by starting at the Target Website instead of PortalGuard
  • IMPORTANT NOTE: SSO using GET requests are NOT affected by the SameSite cookie requirements.  Common applications that avoid the issue altogether are:
    • G Suite
    • Office 365
    • CAS Applications
    • OAuth2/OIDC Applications

• Your PortalGuard server must have its own SSL certificate and be listening on an HTTPS port (typically 443)
  • Even if you have a reverse proxy or load balancer in front of PG handling SSL, that device must still connect to PG via HTTPS/443. 
• Microsoft's URLRewrite extension MUST Be installed on the PortalGuard Server. Please see the following additional KB:
  • How to Enable the PortalGuard Rewrite Rules
• PortalGuard must require SSL for the ASPXAuth cookie (see steps #3 & #4 Below)

1. Navigate to the PortalGuard server and open the 'C:\inetpub\PortalGuard\web.config' file in an administrative text editor.
   • Before making any changes, be sure to save a copy of this file or otherwise back it up. If you have any typos in the proposed change, you'll likely receive a 500 error upon loading the PortalGuard Website.
2. Locate the <forms> element - this should be around line #38.
3. Set the 'requireSSL' attribute to 'true'.
4. Final results should resemble the following (click image to enlarge):
   • 
5. Locate the end of the <rewrite> element - you can search the file for </rewrite> to locate this section quickly.
6. Add the following <outboundRules> element above the </rewrite> element but below the </rules> element:

   • <outboundRules> <clear /> <rule name="Change SameSite Lax" preCondition="Any Set-Cookie"> <match serverVariable="RESPONSE_Set_Cookie" pattern="^(.*)(; SameSite=Lax)(.*)$" /> <action type="Rewrite" value="{R:1}; SameSite=None{R:3}" /> </rule> <rule name="Add SameSite" preCondition="Any Set-Cookie" enabled="true"> <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" /> <action type="Rewrite" value="{R:0}; SameSite=None" replace="true" /> </rule> <rule name="Remove Redundancy" preCondition="Any Set-Cookie" enabled="true"> <match serverVariable="RESPONSE_Set_Cookie" pattern="^(.*)(; SameSite=None)(.*)(; SameSite=None)(.*)$" /> <action type="Rewrite" value="{R:1}{R:3}; SameSite=None{R:5}" replace="true" /> </rule> <preConditions> <preCondition name="Any Set-Cookie"> <add input="{RESPONSE_Set_Cookie}" pattern="." /> </preCondition> </preConditions> </outboundRules>

7. Final changes should resemble the following (click to enlarge):
   • 
     • IMPORTANT NOTE: If you already have an <outboundRules> element within your web.config, you will need to merge the above changes into place.  Your 'web.config' file can only have a single <outboundRules> element defined.
8. Save the changes to the 'web.config' file. 
   • IMPORTANT NOTE: If the 'requireSSL' flag was previously set to 'false', additional steps must be taken by the end-user to benefit from these changes.  It is necessary to terminate any existing session with PortalGuard by completing a logout or completely shutting down the browser.  The 'requireSSL' change affects the formatting of the session cookie used by PortalGuard. If a session is already established with the old cookie settings, the new settings will not take place and the behavior will continue.
9. Open an elevated CMD on the PortalGuard server and run the 'iisreset' comment to ensure the rewrite rules take effect.
10. Navigate to your PortalGuard login page and ensure the page loads as expected.
    • If you receive an HTTP error, revert to the original 'web.config' file and try again.  This should cause the issue to go away. If so, check your 'web.config' file for any typos and try again. 
11. Login to PortalGuard. 
12. Open a new tab in the same browser and navigate to the Website that was generating the error during SSO and confirm that the issue is resolved.

NOTE: Another way to ensure that the changes are in effect is to look at an HTTP trace of the login to PortalGuard. All Set-Cookie response headers should now have both the secure and SameSite=None attributes. The images below are from Telerik Fiddler, but the Network trace in browsers' built-in Developer Tools can be used to see these as well.

REV. 01/2020 | PortalGuard