Intelligent Adaptive Authentication February Release – 23.R1

Intelligent Adaptive Authentication now supports adaptive message-based transaction data signing via virtual signatures. With this feature, you can perform a transaction data signing operation with a signature validation request to the OneSpan Trusted Identity platform API. The generated signature request contains a one-time password (OTP) and signature data fields. The OTP and the fields are sent to the user for confirmation, either via SMS, email, or voice call delivery.

• Generate virtual signature endpoint. A new endpoint has been added for this transaction data signing operation:

  POST /users/{userID@domain}/generate-virtual-signature

  This new endpoint accepts dataFields, credentials, and deliveryMethod as payload.

  The following responses are included:

  • 204: Virtual signature generated.

  • 400: The input is invalid.

  • 403: The command is prohibited for the tenant admin account.

  • 404: User account not found.

  • 409: Failed to generate or deliver a virtual signature.

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

For more information, refer to Integrate adaptive message-based transaction data signing.

In previous versions of Intelligent Adaptive Authentication, each TID microservice had a different implementation for audit logging. The implementation has now been unified. The common aspects of the implementation have been moved to the common-auditing library, where each microservice now uses this library. The custom fields that are specific to the microservice, which were also logged prior to this change, are not affected by this enhancement.

The following TID microservices are impacted:

• authenticator-managementv2

• checkevent

• fido-universal-server

• relying-party

• user-managementv2

In certain error scenarios, mobile clients that use the Orchestration SDK and integrate it with Intelligent Adaptive Authentication receive error messages that are too verbose and contain internal processing details.

The following error messages are affected:

• The authenticator limit has been reached

• No device added

• No device registered

• Wrong device code supplied

• Wrong signature supplied

• User account suspended due to inactivity

• User is locked

• User is disabled

• No authenticators available

• Authenticator not supported

• Could not process encrypted message

• Static password has expired

Status: This issue has been fixed. Correct error messages are now returned to the clients. For unspecific internal server errors, the following generic error message is now returned: An unknown error has occurred.

In addition, the following changes were implemented to improve error messaging for Orchestration SDK clients:

• The error response of the POST /orchestration-commands endpoint now returns a log correlation ID that can be used to identify logs that belong to a certain error.

• If an error message cannot be propagated to the onOrchestrationServerError() callback method because the error command encoding fails, the message of the original error will now be returned as part of the error response of the POST /orchestration-commands endpoint.

This version of Intelligent Adaptive Authentication contains fixes for the following vulnerabilities:

• CVE-2022-42915 (curl vulnerability)

• CVE-2022-42889 (Apache Commons Text vulnerability)

• CVE-2022-37434 (zlib vulnerability)

• CVE-2022-32207 (curl vulnerability)

• CVE-2022-27404 (FreeType vulnerability)

• CVE-2022-23806 (Go vulnerability)

• CVE-2022-22965 (Spring MVC/Spring WebFlux vulnerability)

• CVE-2022-2068 (OpenSSL vulnerability)

• CVE-2022-1292 (OpenSSL vulnerability)

• CVE-2021-45046 (Log4shell vulnerability)

• CVE-2021-44228 (Log4shell vulnerability)

• CVE-2021-43527 (Network Security Services (NSS) vulnerability)

• CVE-2021-31535 (libx11 vulnerability)

• CVE-2021-27568 (netplex json-smart vulnerability)

• CVE-2021-20223 (SQLite vulnerability)

• CVE-2021-3711 (OpenSSL vulnerability)

• CVE-2020-12403 (Network Security Services (NSS) vulnerability)

• CVE-2020-11656 (SQLite vulnerability)

• CVE-2019-20367 (libbsd vulnerability)

• CVE-2019-19646 (SQLite vulnerability)

• CVE-2019-14697 (musl vulnerability)

• CVE-2019-12900 (bzip2 vulnerability)

• CVE-2019-8457 (SQLite vulnerability)

Due to a reference that is incorrectly listed inside the tid-api.json file for the POST /users/{userID@domain}/deregister-fido-uaf-authenticators endpoint, it is not possible to generate the API Client for the OneSpan Trusted Identity platform API.

Status: This issue has been fixed.

Duplicate entries in the FIDO metadata database have caused authenticator registration attempts to fail in certain situations.

Status: This issue has been fixed.

The Secure Messaging service of Intelligent Adaptive Authentication incorrectly returned Failed to generate secure challenge not only for a failed call to generate a secure challenge, but also when calling the service to generate a signing request failed.

Status: This issue has been fixed. Since the error message was not stating clear enough that the cause of the error was an internal issue, the original error message was completely removed. Instead, when either of these two calls fail, Intelligent Adaptive Authentication now returns the following error message: An internal error occurred while attempting to process the request.

In addition, a new error message has been created when a temporary user account has expired: Temporary user account expired. And the wording of other error messages has also been improved and streamlined.

The User Management service, in particular the PUT /users/{userID@domain} endpoint to create users, accepted a null value as delivery method payload for sending a virtual OTP. At the same time, it was not able to map the null value to one of the expected values (Default, SMS, Email, Voice).

Status: This issue has been fixed. The service now maps the null value correctly to Default.

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.