Flow-based authentication

Each target application or service is protected by two flows: an authentication- and an authorization flow.

The purpose of the authentication flow is to:

  • identify the user
  • run multiple authentication steps (and increase authentication strength to the required level)
  • run supporting steps such as mandatory password change or token migration

The authorization flow on the other hand:

  • checks required roles
  • verifies terms of services
  • other similar tasks

Both lists are not final and can also be extended with product and custom steps. Both the authentication- and the authorization flow must be completed successfully to trigger identity propagation.

Application selection

If multiple applications are protected by Airlock IAM, the client has the following options:

  • Directly start an authentication process. This initializes the authentication flow of the Default Target Application.
  • Explicitly select the target application using the application access call with the application ID as an argument.
    Example: POST /auth/rest/public/authentication/applications/app1/access/
    As a result, the call returns, whether access is already granted or indicates the next step required by the client to continue with the flow. The application access call may also inform the client that access is not possible at all, e.g. due to missing user roles.

Note that the Loginapp UI provides additional features that result in selecting the correct authentication flow using the application access call.

Note that it is not possible to directly access the first (or any other) authentication step in a flow. Airlock IAM keeps track of the currently selected flow and the state of its state machine.

The flow must always be selected using the application access call.

Step-up

Step-up describes the upgrade of an already authenticated session to a higher security level by running through at least one additional authentication step.

  • Example:

    • The system protects two target applications: portal and e-banking.

  • The first is protected by a username/password step.
  • The latter additionally requires the completion of an mTAN step.

    • Assume the user first wants to access the portal for which only a username/password is required. If, later on, the user decides to access the e-banking application, the step-up concept exempts the user from repeating the username/password step. He only needs to provide the correct mTAN OTP.

This behavior is implemented with tags and the concept of skip conditions. A step can be skipped in the execution of a flow if all tags defined in the skip condition are already present in the session.

In the example described above, the username and password check step can be skipped, since the success tag(s) from the username password check step are already present in the session. For this to work, steps define the same tag set for Tags On Success and Skip Condition Tags.

The concept of application-triggered step-up is supported in that the triggering application can redirect the browser to the authentication flow containing the step-up step(s).