The sign-on process may contain more than one location where a visitor can authenticate; the "front door", at an approval stage, if there are any APIs exposed by the application etc. It is important to identify the events in the application that require authentication and what authentication requirements each event has (ie an approval process may require a step-up to a stronger form of authentication such as a second factor).

Focusing on the "front-door" authentication, a general web application sign-on process will go through a simple workflow:

Traditional web authentication flow

To change this workflow to support a federated authentication model, when an unauthenticated user appears the application will redirect the users browser to the SSO process. This will result in the user being challenged for authentication at the identity provider and (after a successful authentication) a token returned to the application sign-on process.

The sign-in process is now expecting three user states:

  1. A known user already has an application session (if the user is authorized, the requested page will be rendered)
  2. An unknown user is arriving with a federated security token (where the application will validate that token and if valid, create an application session - the user will then be in state #1)
  3. An unknown user is arriving without a token (the application will redirect the user to the federated sign-in process - the user will re-appear to the application as state #2)

Federated web authentication flow

The results of the authentication request are a token containing proof of authentication and the additional attributes required by the application. The application can use these attributes to create the application session and personalize the application for the user.