Steps of the flow.

Abort Step Acknowledge Message Step Airlock 2FA Activation Letter Order Step Airlock 2FA Activation Step Airlock 2FA Activation Step (with additional Activation) Airlock 2FA Activation Trusted Session Binding Step Airlock 2FA Authentication Step Airlock 2FA Delete Devices Step Airlock 2FA Device Edit Step Airlock 2FA Mobile Only Authentication Step Airlock 2FA Recovery Trusted Session Binding Step Airlock 2FA Usernameless Authentication Step Apply Changes Step Complete Migration Step Cronto Activation Step Cronto Authentication Step Cronto Device Reset Step Cronto Letter Order Step CrontoSign Swiss Push Activation Step Delete All Device Tokens Step Device Token Authentication Step Device Token Registration Step Email Change Verification Step Email Notification Step Email OTP Authentication Step FIDO Authentication Step FIDO Credential Display Name Change Step FIDO Passwordless Authentication Step FIDO Registration Step Failure Step HTTP Basic Authentication Step Kerberos Authentication Step Legacy Email OTP Authentication Step Login From New Device Step Mandatory Password Change Step Matrix Checking Step Migration Selection Step Missing Account Link Step Never Migrate Step No Operation Step OATH OTP Activation Step OATH OTP Authentication Step OAuth 2.0 Consent Step OAuth 2.0 SSO Step OAuth 2.0 Session Reset Step OTP Check via RADIUS Step Password Letter Order Step Password-only Authentication Step Realm Assignment Step Red Flag Raising Step Remember-Me Reset Step Remember-Me Token Generating Step Remember-Me User Identifying Step Representation SSO Ticket Identifying Step Risk Assessment Step Role-based Tag Acquisition Step SAML 2.0 SP User Identifying Step SSI Authentication Step SSI Issuance Step SSI Passwordless Authentication Step SSI Verification Step SSO Ticket Authentication Step Scriptable Step Secret Questions Provisioning Step Selection Step Set Context Data Step Set Password Step Tag Removal Step Terms Of Services Step User Data Edit Step User Identification By Data Step User Identification Step User Identification with FIDO Authentication Step User Lock Step Username Password Authentication Step Username Password with FIDO Authentication Step Vasco OTP Authentication Step Voluntary Password Change Step mTAN Authentication Step mTAN Token Registration Step mTAN Verification Step

Processors get notified about the various stages of the flow and offer hooks to plug in custom logic. These processors realize the entire authentication logic such as incrementing failed login counters or checking of user validity.

The configured processors are extended with the following processors (if not already present):

1. User Enumeration Protection Processor (only if "Prevent User Enumeration" enabled)
2. Temporary Locking Processor (only if "Enable Temporary Locking" enabled)

Custom Flow Processors Default Authentication Processors Default Authorization Processors Default One-Shot Authentication Processors Default Persistency-less Authentication Processors Default Persistency-less Protected Self-Service Processors Default Protected Self-Service Processors Default Public Self-Service Processors Default Technical Client Registration Processors Default Transaction Approval Processors Default User Self-Registration Processors

If enabled, user enumeration is prevented by not revealing what went wrong in a user identifying step ("Stealth Mode"). In particular, all failures because of wrong password or not existing, locked or invalid user are answered with the same generic error code AUTHENTICATION_FAILED. Furthermore, the sessions of the user will be terminated on IAM and on the Airlock Gateway (WAF).

Note that this feature is not compatible with Temporary Locking. It is recommended to configure a "Fixed Response Duration" for failed responses to prevent user enumeration timing attacks.

Important note: This feature only protects against user enumeration if the identifying step identifies the user and at the same time checks a credential, e.g. in case of "Password Authentication" or "Device Token Authentication". If the "User Identifying Step" is used, this feature does not protect against user enumeration.

If enabled, a "User Enumeration Protection Processor" is automatically added to the list of flow processors.

false

Enables Temporary Locking for this flow.

Note: This is only effective, if temporary locking is also enabled in the "Target Applications and Authentication" plugin.

If enabled, a "Temporary Locking Processor" is automatically added to the list of flow processors.

Note: Disabling and re-enabling this feature does not reset temporary locks.

true

If enabled, for any step result that caused an increase in the number of failed attempts, the remaining number of attempts for that factor is returned with the step result.

This feature is not combinable with username enumeration protection.

false

Username transformers may transform the provided username into the single unique user ID required for the flow.
The transformation of a username takes place in the first step before the user is loaded. Note that username transformers have no effect on the propagated username value. Transformers can be chained, i.e. a first transformer could normalize the original name, where the next transformer looks up the normalized name in a database for potential transformation matches.
In contrary to the above description of chaining, a transformer can also signal that it already found the final user ID and the chain must stop after it.
For further details please refer to the documentation of the username transformer plugins.

Airlock 2FA Username Transformer Context Data Username Transformer Identity Username Transformer Lowercase Transformer Primary Key Lookup Regex Username Transformer Template-based Username Transformer Token Data Username Transformer Uppercase Transformer

Whitelist of additional attributes (e.g. headers or REST attributes) for the check password authentication REST call (/<loginapp-uri>/rest/public/authentication/password/check/).

Attributes with matching names and valid values are made available to the flow.

Request Attribute

If enabled, this flow does not consider persistency, i.e. users don't have to exist locally in order to be authenticated. This is typically used with SSO tickets or external authentication using OAuth or SAML.

Persistency-less flows are very limited in their capabilities, in particular:

• Password checks and second factor authentication are not possible.
• The user state (locked, invalid etc.) cannot be verified.
• Identity propagation is limited to the information received from external systems.

Note that configuration validation support is limited. It is essential to test such a flow extensively to ensure it behaves correctly in all situations.

It is recommended to use the "Default Persistency-less Authentication Processors" when using a persistency-less flow.

false