Users receive an error during SSO stating "The account ... is not authorized to access this application".
How and when the SameSite cookie affects users is dictated by a number of factors. The most common causes are listed here for reference:
Modify the PortalGuard website's 'web.config' file to add the Required Rewrite Rule.
<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> |
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