November Release – 24.R2

Orchestration error handling with the POST /orchestration-commands endpoint is deprecated and will be removed in 2025.

To improve the failover behavior in Intelligent Adaptive Authentication, all microservices that were running on the standard MySQL driver were migrated to an advanced Amazon Web Services JDBC wrapper. With this, Intelligent Adaptive Authentication now detects the unavailability of any of the database management systems faster and switches to the failover instance.

The security HTTP headers in the Intelligent Adaptive Authentication API calls were updated to enhance security. If some of these headers break an existing customer integration, please contact OneSpan Support.

Previously, Orchestration in OneSpan Cloud Authentication returned very generic error responses. To improve orchestration error handling and provide unambiguous and well defined error messages, the new Trusted Device microservice has been created to return more specific responses. This microservice is exposed via the POST /orchestration-commands-v2 endpoint.

Orchestration error handling with POST /orchestration-commands is deprecated and will be removed in 2025.

The error responses generated by this endpoint include the following:

Orchestration command error response payload

• readableMessage

• customPayload

• errorType

• flowType

• previousCommandType

• commandSessioId

Client error callback payload

• readableMessage

• customPayload

These payloads and their parameters and/or fields have already been available prior to the implementation of this new feature but new values are used when calling POST /orchestration-commands-v2.

To process the error messages with the new service and endpoint, you must use Orchestration SDK client version 4.24.0 or later.

See also the following:

• Orchestration Error Handling with Trusted Device microservice: general feature description

• Error Messages Returned by Trusted Device Microservice: list of possible error messages

• Migrate to Trusted Device microservice: information about how to migrate to the new microservice

With a new API to query FIDO authenticators, OneSpan Cloud Authentication now offers consolidated management of FIDO authenticator registrations with FIDO2 and FIDO UAF. This allows unified update and deletion operations for authenticators registered with either protocol.

For the implementation of this feature, the registration of FIDO UAF- and FIDO2-based authenticators has been extended. During the registration process, users can provide a customized registration name (registration alias). If not provided, OneSpan Cloud Authentication uses the description of the relevant metadata and creates this alias. OneSpan Cloud Authentication now also generates a unique ID for each registration which can be used for queries to list FIDO-based authenticators.

With the implementation of this new feature, FIDO-based authenticators can now be listed by the following parameters:

• registration ID

• registration name (alias)

• registration type

  This can be FIDO2 or UAF11, as applicable.

• registration time

• KeyID

• AAID

• userID@domain

With this, administrators can query OneSpan Cloud Authentication for a specific user or all users, and list their authenticators by registration type to update, deregister, and/or delete specific authenticator registrations. It also allows end users to list their authenticators to know which authenticators they have registered.

The existing functionality to delete FIDO UAF-only registrations has not been changed and will continue to be available.

The new FIDO authenticator management has also been integrated into the FIDO2 Bank Demo Web App:

• A new page, Manage Registrations, has been added.

  This page displays a list of existing registrations and offers the options to register authenticators, update, and delete registrations. It also provides an additional field with the option to add an alias.

• In the login screen, the Add additional Authenticator button has been replaced with the Manage Registrations button, leading to the new Manage Registrations page.

For more information of this feature in the demo web app, see FIDO2 Bank Demo Web App; for more information on how to integrate this new functionality, see Management of FIDO authenticators.

• Query OneSpan Cloud Authentication for FIDO registrations. To find FIDO authenticator registrations by user, registration type, or a combination of these two, either for a specific user or all users, call the following endpoint:

  GET ​/fido-registrations

  This endpoint accepts userName and registrationType as query parameters.

  • The responses for this endpoint include the following:

    • 200: Registrations returned.

    • 400: The input is invalid.

    • 500: Internal error, sub service failure, server crash.

• Update a FIDO registration. To change the customized registration name, call the following endpoint:

  PATCH ​/fido-registrations/{registrationID}

  This endpoint accepts registrationID as path parameter and registrationName(alias) as payload.

  • The responses for this endpoint include the following:

    • 200: FIDO registration update successful.

    • 400: The input is invalid.

    • 404: FIDO registration not found.

    • 500: Internal error, sub service failure, server crash.

• Delete registrations. To deregister and/or delete registrations, call the following endpoint:

  DELETE ​/fido-registrations/{registrationID}

  This endpoint accepts registrationID as path parameter.

  • The responses for this endpoint include the following:

    • 204: Delete operation successfull.

    • 400: The input is invalid.

    • 404: FIDO registration not found.

    • 500: Internal error, sub service failure, server crash.

OneSpan Cloud Authentication now supports using custom challenges to sign transactions. For 1-step Challenge/Response authentications, the client application generates a custom challenge. This challenge is displayed to the user on the login page. The user enters it into their authenticator and enters the response, e.g. an OTP, on the login page.

The POST /users/{userID@domain}/login endpoint has been extended. A new field, challenge, has been added which can be set to use the custom challenge. The format of the challenge must be a string of numeric or hexadecimal characters with a maximum length of 17 characters.

In some environments where more than one signature authenticator application is used, the signature validation operation may use an incorrect authenticator application to process the request and still create a valid signature.Consider a scenario where two signature authenticator applications exist on an authenticator, SG1 that accepts exactly one data field, and SG2 that accepts two data fields. Now assume that a user attempts a transaction signature validation for a business application that requires two data fields, but mistakenly selects the authenticator application that is accepting only one data field. The signature validation can still be successful, because it uses SG1 to successfully process the request (ignoring the second data field).

Status: This issue has been fixed. Data field handling for performing a signature validation has been improved. Now, any authenticator application that cannot process as many data fields as required by the request will be ignored.

Unassigning an authenticator or moving a user account with assigned authenticators while certain other operations are in progress can corrupt the authenticator BLOB data. This issue can happen rarely, it requires another operation that changes the BLOB data, e.g. generating a virtual signature, almost concurrently as the unassign or move operation.

Status: This issue has been fixed. The update query was improved, the unassign or move operation will fail with a Database update failed attempting to update a digipass application record error message, but the BLOB data will remain correct.

When more than one cryptographic application is available, signature validation could fail. The Authentication component by default always uses the first appropriate application for the validation but if a different application was selected for the signature, this would lead to errors.

To enable the selection of which application to use for response validation, the following optional parameters have been added to the POST /users/{userID@domain}/generate-secure-challenge and POST /users/{userID@domain}/generate-signing-request endpoints:

• cryptoAppIndex

  Index of the authenticator application to be used for response validation.

• cryptoAppName

  Name of the authenticator application to be used for response validation.

These two parameters are mutually exclusive!

This version of OneSpan Cloud Authentication contains fixes for the following vulnerabilities:

• CVE-2023-42363 (BusyBox vulnerability)

• CVE-2023-42366 (BusyBox vulnerability)

• CVE-2024-2511 (OpenSSL vulnerability)

• CVE-2024-4603 (OpenSSL vulnerability)

• CVE-2024-25062 (libxml2 vulnerability)

• CVE-2024-28757 (Expat vulnerability)

• CVE-2024-34459 (libxml2 vulnerability)

On deployments for iOS, push notifications were not working properly. The reason was that the Apple Push Notification service (APNs) API host name was resolved with IPv6 which is, however, not supported by the OneSpan Cloud Authentication infrastructure.

Status: This issue has been fixed. The Push Notification service has been adapted to prioritize host name resolution IPv4.

The input validation for some CDDC data fields has been changed.

As of version 24.R2, the input in the fingerprintRaw and fingerprintHash CDDC input data fields is optional. This applies to the following endpoints:

• POST /events

• POST /users/{userID@domain}/events/validate

• POST /transactions

• POST /users/{userID@domain}/transactions/validate

• POST /users/{userID@domain}/login

• POST /users/register

• POST /users/{userID@domain}/unregister

For a session timeout, OneSpan Cloud Authentication provided an incorrect error message. This was caused by a misalignment of session timeouts between OneSpan Cloud Authentication and the Authentication component.

Status: This issue has been fixed. The value of the OneSpan Cloud Authentication session timeout has been changed to be larger than the session timeout value of the Authentication component.

OneSpan Cloud Authentication returned the same error response for two different errors. The POST /authenticators/{serialNumber}/applications/{applName}/unlock endpoint returned error message 409 - Invalid unlock challenge when either the challenge was not correct or the authenticator does not support the unlock functionality.

Status: This issue has been fixed. When the authenticator does not support the unlock function, OneSpan Cloud Authentication now returns the error message 409 - Unlock Function Not Supported.

An incorrectly handled failover caused a general restart with the result that OneSpan Cloud Authentication was not operative for a few minutes.

Status: This issue has been fixed. Failovers are now handled faster and correctly.

The logs from the audit logger were occasionally absent in certain instances of the Push Notification flow. When a connection timeout between the push and audit services occurred, OneSpan Cloud Authentication did not display the corresponding error message.

Status: This issue has been fixed. Now, in the event of a timeout, the correct error message from the audit logger is displayed for the Push Notification flow.

When the Message Delivery Component (MDC) contacts the Push Notification service and encounters a timeout, it aborts the current request call and blocks further calls for 10 seconds, regardless of the validity of any of these calls. In addition, the timeout value for the Apple Push Notification service (APNs) cannot be configured at all.

Status: This issue has been fixed. The implementation of the flow for push notifications handled with the APNs has been adapted. OneSpan can now configure this value to prevent notification failures for all platforms.

When a user name includes either a leading or trailing blank space, this leads to duplicated or missing entries for that user in the database.

Status: This issue has been fixed. User name validation has been implemented in the following OneSpan Cloud Authentication endpoints:

• POST /users/register

• PUT /users/{userID@domain}

In addition, OneSpan Cloud Authentication now returns error message [400 The input is invalid.] if the user name includes leading or trailing blank spaces.

When the user tries to log in to the MyBank Demo app from an Apple Mac computer with TouchID, the registration with TouchID is successful but the login fails with an internal server error, even though the registration is set to none attestation. The reason for the failure is the fact that Apple Mac computers return a valid aaguid value even when none attestation has been set, but OneSpan Cloud Authentication skips the policy validation for none-attestation registrations.

Status: This issue has been fixed. The implementation of the FIDO2 registration has been adjusted to always store a zero-value in the registration record when none attestation is used.

A sudden increase in unknown errors during remote transaction steps occurred. The reason for this is that some of the requests for these transactions included data from the Client Device Data Collector (CDDC), a component of the Risk Management component. In addition, the time between generating a transaction request, checking the session status and validating the signature sometimes exceeded the configured timeout of 60 seconds.

The original design of OneSpan Cloud Authentication foresaw the integration of the Risk Management component even though this component is only involved for usage with Intelligent Adaptive Authentication. Consequently, all requests that include CDDC data will be directed to the Risk Management component, even if it is not available on the customer tenant.

Status: This issue has been fixed. The usage of the Risk Management component with OneSpan Cloud Authentication can now be configured per tenant. With this, requests containing CDDC data will not be automatically directed to the Risk Management component.

Different requests failed and services were not available due to disconnected clients. The reason for this was that the Check Event service of OneSpan Cloud Authentication waited too long for a response from the Risk Management component which caused the web server environment to run out of available threads for processing new requests. This ultimately led to outages of tenants and OneSpan Cloud Authentication was no longer able to process any requests.

Status: This issue has been fixed. The timeout period between the Check Event service and the Risk Management component has been reduced.

The POST /users/{userID@domain}/transactions/validate endpoint returns an incorrect error message if the transaction amount field is provided from the data type number, and if the transaction amount is large. In this case, the endpoint should return the error message "Invalid value type", because the transaction amount field was provided as a number and not as a String. Instead, it returns the incorrect error message "Amount: Value must follow -^-?[0-9]{1,20}(\\.[0-9]{1,3})?$,".

Solution: The transaction amount fields in the request body of the transactions/validate endpoint need to be provided as a String. Ensure that the value in the JSON request body is wrapped in double quotes.

OneSpan Cloud Authentication supports the following versions of the Orchestration SDK Client:

• 5.9.1

• 5.9.0

• 5.8.1

• 5.8.0

• 5.7.0

• 5.6.4