The user visits the URL for their Tines application, e.g.
The user's browser doesn't yet have a session cookie for the application. The session cookie, if present, would provide a pointer to session data stored in a Redis cluster that would include the authenticated user's ID. As that session information is missing, the browser is redirected to the SAML IdP for their Tines instance. The redirect includes the necessary SAML request data. Out of the box, a Tines instance provides its own IdP, at
https://tines.example.com/saml_idp, in our example.
The default SAML IdP provided out of the box by Tines authenticates users via magic links sent to their email address. The user is prompted for and provides their email address,
The SAML IdP writes a database record with an identifier and the correct SAML response to later provide back to the SP and sends an email to
email@example.com a link like:
When the user loads that link from their email inbox, the SAML IdP retrieves the database record associated with the given identifier and redirects the user back to the application proper (which is a SAML SP) at
https://tines.example.com/users/saml/authwith the correct SAML response.
The application now knows that the user is indeed
firstname.lastname@example.org. It next validates that
email@example.com an active account on the Tines application by looking for a corresponding user record in the database using that email address. If a user record is found, an entry is created in the Redis cluster that includes the record's ID. A session cookie with the correct identifier for retrieving that entry from Redis is created. The user's browser is redirected back to the page that they initially requested,
The user's browser loads the page
https://tines.example.com, this time providing a correct session cookie, which in turn allows the backend to load the authenticated user's ID from Redis and the user record from the database. The user is now logged in.