Endless Login attempts for many add-ons which are already logged on the SSO, but not on Confluence

[Darren Ong]

Pre-requisites:

• User not login to Confluence but already logged in to the SSO. 
  (Example, already logged in to access GDrive, but yet to login to Confluence)
• Public Page (Accessible for Anoymous user) containing embedded GDrive or Workflow add-on.

Observations:

• The add-on will trigger the SAML SSO, with no end.
• Each session has a JSESSIONID created.
• However, each SSO retry mechanism with a new JSESSIONID.
• Happened on Confluence Data Center v9.2.3.
• Does not happen on Confluence Data Center 8.5.17.
  • On 8,5.17, user will see the gdrive or no access.
    Workflow will be shown emptied.

I have shared my observation with the vendor who manages the SAML SSO add-on, and was advised on this:

the user is correctly redirected to the SAML endpoint and the JESSIONID is JSESSIONID=8F2112E4AF58EB63F0E0AF545CD4C15B, then a redirection happens to GDrive (the SAML plugin doesn’t do that), and you can see that the JESSIONID is different JSESSIONID=2C7CE3E0069C21394940E6509B2A5C86. Since the session is different than the one that the authentication started with, the SSO mechanism kicks off again and redirects the user to the IdP for an authentication. The plugin doesn’t kill nor create any session cookie by its own at all. It uses the JSESSIONID that’s created by Atlassian/tomcat by default when the user accesses the Atlassian product.

Hopefully you can share with me what is wrong or guide me to the correct path.