Creates the message for transaction approval that will be displayed on the user's device.

Airlock 2FA Message Provider

If Push-to-All for One-Touch is enabled, device selection is never required for One-Touch. Push notifications are sent to all devices of a user and approval can be given on any of the devices.

The combination of Push-to-All and "Lock User on Fraud" could have undesired effects, because users might report fraud in legitimate use-cases.

If an AuthTokenId is provided, notifications are only sent to the device specified in the AuthTokenId.

false

Whether to enable short-lived Online QR Codes. Unlike regular Online QR Codes, these are refreshed regularly, allowing for shorter individual validities.

Shorter validities enhance security, since forwarding a QR code to victims and tricking them to scan the QR code becomes more difficult if the available time window is small.

false

The maximum amount of time in seconds for which an Online QR Code is valid after it is first displayed to the end user (ignoring latency). This duration includes the time defined for the validity overlap. It only limits the time for scanning the QR code, not for the confirmation or approval afterwards.

Security Notice: The validity duration represents the attack window. Choosing a small validity makes attacks more difficult, in cases where an attacker attempts to forward a QR code to a victim for scanning.

This setting is only active if short-lived Online QR Codes are enabled.

10

Defines the duration in seconds during which the previously displayed QR Code is still valid after being replaced by the next QR code in sequence.

This provides time for pending requests to complete and ensures that a valid QR code is displayed at every moment in time, provided that there are no network or performance issues.

The validity overlap must meet the following criteria:

• It must be smaller than half the overall validity of the QR code.
• It must be larger than the Loginapp UI polling interval (1s) plus the network latency (IAM backend → Loginapp UI plus Mobile Device → Futurae Backend).
  Note that the polling interval may differ for custom user interfaces.

This setting is only active if short-lived Online QR Codes are enabled.

3

Maximum duration in seconds during which short-lived Online QR Codes are displayed until a session timeout occurs.

This setting is used exclusively for short-lived Online QR Codes. It has no effect if short-lived Online QR Codes are disabled.

60

Settings of Airlock 2FA.

Airlock 2FA Settings

The URI used on iOS to switch from the authentication app (Airlock 2FA or compatible) back to the main app where the authentication was initiated. This value is not applicable if the authentication is directly performed by the main app. Furthermore, this value is ignored on Android, where the back stack mechanism is used instead.

Allows to override the scheme of the mobile authentication URI which is returned by the approval step. The scheme of the authentication URI determines, which app to open on the mobile device for authentication. This is useful when migrating from one authentication app (such as Airlock 2FA) to a different authentication app. For example, during a migration, this step can be used to support the previous authentication app by overriding the scheme of the new app with the scheme of the previous app.

airlock2fa

OneApp-1

Priority list of all factors that can be used in this approval step. Only factors that are in this list can be used. The factors are offered in the configured order.

One-Touch and Online QR Code must come before all other factors. It is recommended to include at least one offline factor.

Available factors:

• One-Touch: a push message is sent to the user's mobile app, where it must be approved. This is an online factor and will require device selection if the user has multiple devices.
• Online QR Code: a QR code is displayed in the browser, which has to be scanned by a mobile app and approved there. This is an online factor. No prior device selection is required.
• Offline QR Code: a QR code is displayed in the browser which has to be scanned by a mobile app or hardware token. The device displays a code (OTP) that must be entered manually in the browser. This is an offline factor and will require device selection if the user has multiple devices.
• Passcode: the device (mobile app or hardware token) generates a time-dependent code (OTP) that has to be entered manually. This is an offline factor. No prior device selection is required.
• Mobile Only: the approval is handled directly by the mobile app. This is an online factor. No prior device selection is required. There is no fallback from this factor to other factors or vice-versa. Therefore, the only use case for combining this with other factors is in transaction approval, where the factor previously used for authentication determines whether mobile-only or another factor will be used. Since there is no way to use any factors configured after Mobile Only, it should always be configured as the last factor.

AuthTokenId:
The AuthTokenId identifies the device and factor that was used during the authentication and links it to the approval process. It is used to ensure that, for certain flows, the same device must perform the approval. The AuthTokenId is evaluated only for transaction approval. It has no effect on other flow types.

When the AuthTokenId is present in the transaction approval flow and contains the factor Mobile Only:

• and the Mobile Only factor is configured in this approval step: the Mobile Only factor will be enforced.
• and the Mobile Only factor is not configured in this approval step: any of the configured factors may be used.

[One-Touch, Offline QR Code, Mobile Only]

If enabled, devices in cooldown cannot be used for approval.

If disabled, this step ignores the "Cooldown Period" for new devices configured in the "Airlock 2FA Settings". This is typically used for approval steps that protect low-risk operations, which can also be performed with devices in cooldown.

If no "Cooldown Period" is defined, enabling this property has no effect.

true

If enabled, the device choices provided for device selection include usage information for each device: the time of enrollment ("enrolledAt") and the time of last use ("lastUsedAt").

The information is revealed to anyone completing the flow steps preceding the device selection. Enabling this property in flows accessible without prior strong authentication may lead to unwanted information disclosure.

false

Manually selectable Goto targets. These are steps to which the user can chose to jump when this is the current flow step.

Interactive Goto Target

Steps that can be dynamically activated while in this step.

Dynamic Step Activation

If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.

Account Linking Required Red Flag Condition Active Authentication Method Airlock 2FA Device Deletion Possible Airlock 2FA was used for login (Transaction Approval only) Always False Always True Boolean Condition Cronto Activation Possible Cronto Activation Required Cronto Device Removal Possible Cronto Letter Order Condition Cronto was used for login (Transaction Approval only) CrontoSign Swiss Push Activation Possible Email OTP was used for login (Transaction Approval only) FIDO Credential Removal Possible FIDO was used for login (Transaction Approval only) First Usage of Device Has Cronto Account Has Cronto Device Has Device Token Has Email Address Has FIDO Credential Has Matching Role Has Matrix Card Has OATH OTP Token Has Password Has Suitable Airlock 2FA Device Has Tag Has Vasco OTP Token Has mTAN Activation Letter Has mTAN Token IdP-Initiated SSO Flow On SP Logical AND Logical NOT Logical OR Matching Username Never Migrate Possible New Device Condition Next Authentication Method-based Migration Condition OAuth 2.0 Authorization Code Grant In Progress OIDC prompt=none Condition Password Letter Order Interval Condition Public Self-Service Allowed Condition Red Flag Raised Request Has SSO Ticket Step Activated String Regex Condition User Attribute Is Unique User Identified User Represented Condition Vasco Activation Possible mTAN Number Changed mTAN Number Deletion Possible mTAN Number Registration Possible mTAN was used for login (Transaction Approval only)

This step is executed only if the configured pre condition is fulfilled. If the condition is not fulfilled, the step and flow execution fail immediately. The step is not initialized and no step method can be called. If no condition is configured, the behavior is that of a fulfilled pre condition.

Account Linking Required Red Flag Condition Active Authentication Method Airlock 2FA Device Deletion Possible Airlock 2FA was used for login (Transaction Approval only) Always False Always True Boolean Condition Cronto Activation Possible Cronto Activation Required Cronto Device Removal Possible Cronto Letter Order Condition Cronto was used for login (Transaction Approval only) CrontoSign Swiss Push Activation Possible Email OTP was used for login (Transaction Approval only) FIDO Credential Removal Possible FIDO was used for login (Transaction Approval only) First Usage of Device Has Cronto Account Has Cronto Device Has Device Token Has Email Address Has FIDO Credential Has Matching Role Has Matrix Card Has OATH OTP Token Has Password Has Suitable Airlock 2FA Device Has Tag Has Vasco OTP Token Has mTAN Activation Letter Has mTAN Token IdP-Initiated SSO Flow On SP Logical AND Logical NOT Logical OR Matching Username Never Migrate Possible New Device Condition Next Authentication Method-based Migration Condition OAuth 2.0 Authorization Code Grant In Progress OIDC prompt=none Condition Password Letter Order Interval Condition Public Self-Service Allowed Condition Red Flag Raised Request Has SSO Ticket Step Activated String Regex Condition User Attribute Is Unique User Identified User Represented Condition Vasco Activation Possible mTAN Number Changed mTAN Number Deletion Possible mTAN Number Registration Possible mTAN was used for login (Transaction Approval only)

If enabled, this step is only executed if it has been dynamically activated from a previous step. If it has not been activated, the step is skipped (equivalent to when the skip condition is fulfilled).

false

This step grants these tags if it completes successfully.

Tag

ID of this step. This is only needed if this step is the target of a goto action or if this step requires activation.

Step ID

If the step fails (no retry) and a goto target for the error code is defined here, the flow does not fail and instead a "goto" to the specified target step is executed. Note that even when the "goto" is executed, any error codes that are considered a failed factor attempt will still increment the "failed attempts" counter, and may lead to the user being locked. Therefore, this may still result in a failed flow.

A typical application of this feature is switching to an alternative authentication factor step, if an external service (e.g. Futurae server, SMS gateway) is not available (error code EXTERNAL_SERVICE_UNAVAILABLE with "Strict Counting" disabled, which will not increment the "failed attempts" counter). Other error codes can be found in the IAM REST documentation, in both the general "Error Codes" section and in the documentation of specific endpoints.

Step ID

A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.

Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.

Custom attributes are not returned for 'retrieve' endpoints.

Additional Password Check Attribute Map Airlock 2FA Authentication Data Map Airlock 2FA Login ID Parameter Authentication Data Map Conditional Value Map Provider Context Data Map Edited Context Data Map Generic Session Attribute Value Map Provider HTTP Request Information Map OAuth 2.0 Credential Context Data Map OAuth 2.0 Tokens Map Roles Provider SSI Verification Data Provider SSO Ticket Context Data Provider Script Execution Result Value Map Provider Transaction Approval Parameters Map Transforming Value Map Provider User Identity Map User Passwords Map User Statistics Map Value Provider Map mTAN Token Flow Value Map

A list of custom attributes that are added to the REST response in case of a step failure during step execution. Unexpected failures leading to HTTP response status code 500 do not contain these attributes.

Additional Password Check Attribute Map Airlock 2FA Authentication Data Map Airlock 2FA Login ID Parameter Authentication Data Map Conditional Value Map Provider Context Data Map Edited Context Data Map Generic Session Attribute Value Map Provider HTTP Request Information Map OAuth 2.0 Credential Context Data Map OAuth 2.0 Tokens Map Roles Provider SSI Verification Data Provider SSO Ticket Context Data Provider Script Execution Result Value Map Provider Transaction Approval Parameters Map Transforming Value Map Provider User Identity Map User Passwords Map User Statistics Map Value Provider Map mTAN Token Flow Value Map