Shared Browser Sessions and SAML Single Sign-On

Help
, , , ,
1

We have enabled Single Sign-On for an organization using ADFS that we are working with via an enterprise SAML connection. In this particular scenario, the organization hosts a SAML identity provider, and we have enabled Auth0 as a service provider. Unfortunately, we are experiencing a problem where two users using our web application in the same browser session can result in the second user logging in as the first user. Here’s the workflow:

  1. User #1 enters his/her email in to the Auth0 Lock in our application that ends in “ssodomain.org”. The “Single Sign-On Enabled” message appears.
  2. User #1 gets redirected to the organization’s SAML login site.
  3. User #1 authenticates, and gets redirected back to our application.
  4. User #1 logs out of our application and leaves the browser on the login page.
  5. User #2, using the same browser session as User #1, enters his/her email that ends in “ssodomain.org”. The “Single Sign-On Enabled” message appears.
  6. User #2, gets redirected to the organization’s SAML login site.
  7. The organization’s SAML login site detects a pre-existing valid cookie (or some other local browser-based persistence) for User #1, automatically uses that for authentication, then immediately redirects User #2 back to our application without giving User #2 a chance to address this.
  8. User #2 is now logged into our application as User #1. (Gah!)

For clarity, the logout on Step #4 is an “application session” logout as described in the Auth0 Logout documentation. If we swapped this logout to be of type “Auth0 session,” would that allow the second user an opportunity to log in as him or herself? Is this something that needs to be changed as part of our SAML connection configuration with this organization, or something the organization should be changing on their end? We are confident that the “Identity Provider session” logout will allow the second user to login, but we consider that to have a poor user experience.

We took a stab at solving this by performing an “Identity Provider session” logout for all SSO users by setting the federated parameter into a logout call to Auth0. Expectedly, that drove our testers crazy. Kicking them out of other web applications backed by that IdP session was a very frustrating user experience.

2

This ended up having to do with an overlooked ADFS configuration setting.

When a user logged into the organization’s SAML login site, a cookie was set. When any user returned to that SAML login site via this authentication workflow, the login site checked for that cookie. If the cookie had not yet expired, it would automatically authenticate the visiting user as the one who initially logged in and set the cookie.

The way to disable this cookie from being set revolves around an authentication policy in ADFS for the relevant relying party (our tenant in Auth0). Specifically, there is a checkbox labeled “Users are required to provide credentials each time at sign in” that must be checked in order to disable the setting of this cookie. Once that checkbox was checked, each user had to re-authenticate with their IdP whenever they were redirected from our application for a new login session.