SSO ticket authentication in the Loginapp REST API

SSO tickets can be used to authenticate users in the Loginapp REST API.

Consider the security recommendations in Single sign-on (SSO) ticket authentication.

The SSO Ticket Authentication Step plugin is used to extract an SSO ticket from the request, validate it, identify the user, and issue tags in the authentication session.

The most important configuration settings are:

Security Implications of SSO Ticket Repository Choice

All successfully accepted SSO tickets are stored in order to prevent replay attacks.

There are two possibilities to store SSO tickets:

• In memory with plugin In-Memory Accepted SSO Tickets Repository
  This is simple and straightforward in configuration and okay for single-instance deployments. If more than one IAM instance is active, their list of accepted SSO tickets is not shared.
• On the database with plugin Persistent Accepted SSO Tickets Repository
  This requires a database connection configuration, an up-to-date database schema (at least IAM 8.1 DB schema), and the configuration of the Accepted SSO Tickets Clean-up Task in the Service Container module.
  This configuration is more secure and prevents replay attacks even across multiple IAM instances.

It is highly recommended to use the Persistent Accepted SSO Tickets Repository for production.

To configure an authentication flow that authenticates users with SSO tickets, do the following:

1. Go to:
   Loginapp >> Applications and Authentication >> Applications >> Target Application (create a new one if required)
2. In the target application's Authentication Flow, add an SSO Ticket Authentication Step as the first step.
3. Configure the SSO Ticket Authentication Step as required.
4. Optionally add other authentication steps after the SSO Ticket Authentication Step (e.g. 2nd factor, terms of services, or alike).
5. Users can now be authenticated by sending an SSO ticket.

The following example HTTP request to access the application with id sso-token-test bears an SSO ticket in the HTTP header X-Logon-Token. It works with the SSO Header Ticket Extractor plugin and the JWT Ticket Decoder plugin (JWT ticket is truncated).

POST https://www.airlock.com/auth-login/rest/public/authentication/applications/sso-ticket-test/access
 
X-Logon-Token: eyJhbGciOiJI…  

Make sure the HTTP header bearing the SSO token, e.g. X-Logon-Token, is in the Allow List of your Airlock Gateway.

The required HTTP header has to be added on the corresponding mapping(s) in tab Request Actions >> Allow List >> Additional allowed headers.

A typical application of the SSO Ticket Authentication Step is to accept SSO tickets as an alternative to interactive authentication. In other words, the SSO ticket is only used if it is present in the request.

To do so, configure the following flow:

1. Go to:
   Loginapp >> Applications and Authentication >> Applications >> Target Application (create a new one if required)
2. In the target application's Authentication Flow, add a Selection Step as the first step.
3. In the list of Available Options, add a Selection Option with the following settings.
• -In the list of steps, configure the SSO Ticket Authentication Step (see simple flow above for details).
• -As Condition, configure the Request Has SSO Ticket.
4. As Fallback Flow (in the Selection Step), configure the flow to be used if no SSO ticket is available in the request. This could be, for example, a Username Password Authentication Step.
5. Users can now be authenticated by either presenting a valid SSO ticket or passing the alternative flow steps (e.g. enter username and password).

• Single sign-on (SSO) ticket authentication
• SSO tickets in the Loginapp UI