Airlock IAM 8.3 - Changelog

OAuth 2.0/OIDC now supports redirect_uri using a private-use scheme (containing only one slash after the colon, e.g., com.example.app:/oauth) in the default SPA.

The Set Context Data Step now produces Context Data Changed events.

The Airlock 2FA Authentication Data Map now correctly respects the cooldown state of the authentication device.

The Use STARTTLS behavior of the SMTP Email Server is now correct: It uses TLS at all times.

The Discovery Endpoint lookup in the OAuth 2.0 token exchange is now cached using the same timeout as the JWKS response.

The Airlock 2FA Delete Devices Step is now also available for protected self-service flows (already available in authentication flows). The step now supports different deletion policies for different use cases. Additionally, the step now produces an Airlock 2FA Device Deleted event that can be subscribed to.

It is now possible to define a cooldown period for newly registered Airlock2FA devices. During this period, new devices can only be used for low-risk authentication or action approvals. IAM provides several event notifications that inform the end-user about the cooldown period process, including the new Airlock 2FA Device in Cooldown Used event. Furthermore, the new value provider Airlock 2FA Cooldown Information informs the backend application about the cooldown status of the affected Airlock 2FA device. For all details, see Airlock 2FA cooldown period feature.

For the One-Touch option of the Airlock 2FA authentication method, IAM now provides the Push-to-All feature. If an end-user uses several Airlock 2FA devices, the feature pushes messages to all devices simultaneously. This prevents users from having to interactively select a device. The feature can be enabled on several Airlock 2FA authentication and approval steps.

There is a new flow step User Identification by Data Step. This step allows the identification of users in authentication and public self-service flows by the user's context data. Which context data to use is configurable on the step.

There is a new IAM-wide REST endpoint, which returns all public keys used for signing JWTs in the Loginapp.

• This includes public keys from the following plugins:
• JWT Ticket RSA Signer Settings
• JWT Ticket EC Signer Settings
• Oauth 2.0 and OIDC Private Key JWT Client Authentication
• OAuth 2.0 and OIDC JWT Access Token Private Key Signature
• OIDC ID Token Private Key Signature

For more details on this new JWKS endpoint, see JWKS endpoint.

It is now possible to define a list of FIDO transport types that are allowed for authentication. Thus, you can limit the number of FIDO transport types to be used in your setup. Examples of FIDO transport types are Bluetooth, NFC, USB, internal, etc.

Limiting the allowed FIDO transport types is only possible if FIDO is used as second factor in an authentication flow. The feature doesn't work for FIDO passwordless authentication.

To configure the allowed FIDO transport types in the Config Editor, go to MAIN Settings >> Authentication Settings >> FIDO Settings. Specify the list of FIDO transport types in section Authentication Settings, property Authentication Transports.

The new event Filtered Flow Event allows Loginapp event subscribers to filter events based on flow ID, step ID, or flow type (authentication, public self-service, etc.).

Additionally, events that are emitted during a step with a step ID now always include this step ID in the event source data. This was not always the case in the past. For more information, see Filtered Flow Event. Note that the new event is not available for Adminapp event subscribers.

Loginapp: In some audit log messages, wrong Service Container prefixes appeared. These prefixes have been removed.

The following five new properties have been added to the Microgateway mapping templates:

• global.path.adminapp
• global.path.loginapp
• global.path.transactionApproval
• global.path.apiPolicyService
• global.path.serviceContainer

These properties define the paths to the respective IAM modules. Previously, the paths were hardcoded to the format <instanceName>-<module>/, which was incompatible with the options available in the instance.properties file to change the module path (e.g., iam.adminapp.url.path).

It is now possible to manually determine when the flow continuation token is consumed in the flow. For more information, see Consumption of the Flow Continuation Token. In Continuation flow configuration with manual token consumption, it is explained how to configure the manual token consumption.

Client overrides enable client-specific configurations to supersede authorization server defaults. This includes overrides for access and ID token claims to add additional claims or to write client-specific values to existing claims. The use of PKCE, authentication settings, scopes, and flow settings can be configured per client.

PAR (Pushded Authoriatzion Requests) is now supported by the OAuth 2.0/OIDC Authorization Server. For more information, see PAR - Pushed Authorization Request on the AS/OP.

Tags and flow attributes can now be persisted in the database. When enabled, these values are evaluated and stored during ID propagation, allowing them to be used for creating access and ID token claims both initially and during token refresh. Subsequent changes to context data items will not affect the token contents.

Fixed an incorrect collation on oauth_session.id with a database migration script.

There is a new event User Roles Changed, which is triggered when an administrator changes the user's roles in the Adminapp. The corresponding event subscriber notifies the subscriber each time a role is changed. The event info contains information about the old, new, added, and/or removed roles of the affected user.

Each time an end-user, IAM administrator, or IAM tech-client is locked in the Adminapp, the lock reason is now logged. For end-users and administrators, the log reason appears in the helpdesk logs, for tech-clients in the audit logs.

A more specific technical error page is shown if the IAM backend is not available (HTTP 503).

The IAM docker Image is now published on quay.io. Contact support to get access. For more information, see Getting the Docker image.

The correlation ID can now be provided with the HTTP Request Information Map value provider. This allows further use of the correlation ID, e.g., in the Scriptable Step.

It is now possible to disable the Config Editor, by setting the iam.config-editor.enabled property in the instance.properties file to "false". In this case, the Config Editor is not started upon startup of the Adminapp, and the Configuration item is not visible in the menu of the Adminapp. By default, the Config Editor is still enabled (iam.config-editor.enabled = true).

The new property Escape Values in HTML allows escaping all HTML values in an email. It is enabled by default.

• The following plugins provide the new property:
• Flow-based Password Reset,
• Send Email Link Step,
• Email Message Provider,
• Email Notification Step, and
• Email Identity Verification Step.

The new Transforming Value Map Provider plugin supports the selective escaping of specific HTML values only. Together with the HTML String Escaper plugin, the new plugin applies transformations of HTML strings to all values provided by a configured list of value provider maps.

For more information, see Escaping HTML values in emails.

• Some dependency upgrades:
• Airlock IAM has been updated to Java 21 (AI-17838)
• Airlock IAM has been updated to Tomcat version 10.1 (AI-17199)

The structured Webserver and Access Log console output now writes the log timestamp in a time field, to be consistent with the Module Detail logs. The already existing field timestamp is preserved for backwards-compatibility.

Fixed the configuration migration from 7.7 to 8.0. Now, the OAuth 2.0 Client Credentials Grant configuration is correctly migrated.