| | | Client failures during FIDO/Passkey registration and verification are reported to the server. This allows for better logs and makes it possible to use the On Failure Gotos flow step feature to continue the flow. If the user's browser does not support WebAuthn during FIDO/Passkey registration or verification, the flow now fails instead of being aborted. Verify the UI settings for "on failure" and "on cancel" targets or use the On Failure Gotos step flow feature. See On-failure Goto (flow concept) and FIDO configuration overview. | |
| | | Accidentally, the FIDO Public Self-Service Approval Step could be configured in protected self-service flows. This is no longer the case. Use the FIDO Self-Service Approval Step instead. | |
| | | During FIDO/Passkey passkey registration in the Loginapp, the FIDO key's display name can be auto-generated based on the AAGUID of the FIDO key. It can be edited in a subsequent step. During config migration of FIDO steps, the AAGUID mappings are moved from the FIDO registration self-service settings to the global FIDO Settings This may result in an undesirable configuration if AAGUID mappings of multiple FIDO steps are migrated into the same global FIDO settings object. It is recommended to review the AAGUID settings in the global FIDO settings after migration. See also Use case: FIDO passkey registration self-service and Use case: FIDO token migration self-service. | |
| | | FIDO/Passkey transports (UBS, NFC, BLE, device-bound, etc.) can now be stored during the registration of a FIDO key or Passkey. If enabled, they will be used by IAM in the authentication challenge reducing the list of offered devices to the end-user. To use this feature, the database schema upgrade is mandatory. It is strongly recommended to upgrade the database schema even if not using this new feature. See FIDO authentication (WebAuthn, U2F, CTAP). | |
| | | Access to the auth flow REST endpoint<loginapp>/rest/public/authentication can now be restricted using conditions. For backward compatibility, it is still publicly available for existing (migrated) configurations. Consider restricting access: Loginapp >> Applications and Authentication >> Authentication Information Accessible Condition. Security Note: If publicly available, this endpoint could be exploited for user enumeration attacks. To prevent these attacks, it is recommended that access to the endpoint is restricted to authenticated users only. | |
| | | The Set Context Data Step in the authentication flow did not emit a Context Data Event. This has been fixed and an event is now emitted. Configured event subscribers processing the Context Data Event may have to be adapted because the event may now also come from the Set Context Data Step. | |
Loginapp, Transaction Approval | | | Unexpected requests to flow REST endpoints (error code UNEXPECTED_CALL ) no longer terminate the flow and return a 400 status code instead of 403 . There should be no need to adapt any REST clients since the error code UNEXPECTED_CALL was already specified to return 400 or 403 . Moreover, all REST endpoints are documented to return a 400 response code possibly. If a (non-spec-compliant) REST client relies on the error code UNEXPECTED_CALL to be always returned in conjunction with 403 , it must be adapted. | |
| | | Show password option on password input fields in Loginapp UI: The new variable iam-show-password-toggle in the Loginapp Design Kit allows the end user to see passwords entered in the Loginapp UI in plain. Although the new variable is set to false, its introduction may have an impact on complex UI customizations. It is recommended to check the styling of input fields - especially password input fields. See also Changing the Loginapp UI appearance with the Design Kit. | |
| | | The iam reset CLI command no longer accepts filenames for the parameter -f that doesn't end with a .xml or .yaml suffix. In case the command was used in a script, and the filename was specified with a different extension, the script needs to be updated. | |
| | | If custom web.xml files are used, the "internal" part has to be removed from all referenced com.airlock.iam package names. | |
| | | IAM now treats connection failures to connected systems as FATAL errors. Several log messages have been updated with a new log level and new log messages have been created. Systems processing IAM logs and relying on the previously used log level may have to be adapted. See Loglevel FATAL. | |