Summary
When re-entering a password using SAML to approve a document or complete a task (digital signature using SAML), after correctly entering the password, the signature sometimes does not get applied but instead the user sees and error "Max Session Reached" or other errors because the user is suddenly logged out.
This behavior started happening from Chrome 80 or Edge 86 (released in 2020) and happens for all versions of WebCenter.
Symptoms
Depending on the WebCenter version, the symptoms are slightly different, but the problem is the same.
Symptoms in WebCenter 20.0, 21.03, 21.07, 21.11:
- After the user re-enters his password using SAML to complete a task or approve a document, he sometimes sees a message in the popup where he entered his password: "Max Session Reached" and "Expire My Sessions".
Symptoms in WebCenter 22.03 and later:
- After the user re-enters his password using SAML to complete a task or approve a document, he sometimes gets automatically logged out. It is not very clear though as he stays on the same page, but from the moment the user tries to navigate he will see that he is no longer logged in. This sudden log out is usually also accompanied with other errors.
Currently this only happens on Chromium browsers (Chrome, Edge) since Chrome version 80 and Edge version 86. (source)
Why is this happening?
The reason this is happening is because the browser loses the session cookie. This seems to be happening at random. When the cookie is lost the browser indicates that this is because the cookie is set to SameSite=Lax
which is the new default since Chrome 80 and Edge 86.
The solution is to make sure the cookie is not set to SameSite=Lax
(default) by explicitly specifying that it should be SameSite=None
.
However, SameSite=None
can only be set for secure cookies (= when the server is accessed over HTTPS). For that reason it is difficult to set this header in Tomcat itself.
Additionally, when using the WebCenter Task plugin to connect to WebCenter, for older versions of InDesign, like InDesign 2020, the Task plugin uses an older version of Chrome which does not support SameSite=None
. This means the header can also not always be set. It depends on the browser used to access WebCenter.
Solution
For WebCenter, IIS is handling HTTPS, it makes sense to set the SameSite=None
in IIS as well. IIS can also more easily handle the requirements to pass different headers depending on the browser used to access WebCenter.
Before you start, important to note:
- The solution currently assumes the server is only reachable over HTTPS. The solution is currently not adapted to also work over HTTP.
- WebCenter will become temporary unavailable while doing this configuration
Setting it up:
- Go to IIS Manager
- Click on the site in the left side panel
In the Feature View click URL Rewrite.
- In the Actions pane on the right-hand side, click Add rules…
- In the Add Rules dialog box, under Outbound Rules select Blank Rule and click OK.
- Now we need to add the actual information in the rule (instructions below the screenshot):
Screenshot:

Instructions:- Name: sameSiteCookies
- Match:
- Matching scope: Server Variable
- Variable name:
RESPONSE_Set-Cookie
- Variable value: Matches the Pattern Using: Regular Expression
- Pattern:
^(.*)(JSESSIONID)(=.*)$
- Conditions:
- Click Add and add the condition... (instructions below the screenshot)
Screenshot:

Instructions:
- Condition input: {HTTP_USER_AGENT}
- Check if input string: Does Not Match the Pattern
- Pattern: .
*Chrome\/(55|56|57|58|59|60|61|62|63|64|65|66)\..*
- Click Ok
- Actions:
- Action type: Rewrite
- Value: {R:0};SameSite=none
- Save the new outbound rule
- Go back to the site in the left side panel
- In the Actions pane on the right-hand side, click Restart... to start the server (it went down when the rule was saved)