Version 3.26 (August 2024)

By default, the SOAP handlers ignore underlying exceptions, and always return a generic "Service is not available" error message. You can now configure the SOAP wrappers, so that underlying exceptions are re-thrown (as IdentikeyConnectionException) and can be properly handled by the application.

For the Java wrappers, this behavior can be configured with the ConfigurationBean.setRethrowOnConnectionError() method.

For the .NET wrappers, this behavior can be configured via the RethrowOnConnectionError setting in the application configuration file (app.config).

The SDK now fully supports the Jakarta EE platform. The package includes project files and artifacts for the SOAP client and the SOAP wrapper that are compliant with Jakarta EE 9 and provide Java 11 target compatibility.

Description: Authentication and signature validation commands return the serial number of the used authenticator (CREDFLD_SERIAL_NO). In case of MDL, this field contains the authenticator instance number, e.g. VDS1000120-1. This was not the case for the authUser command.

Affects: OAS Authentication SDK 3.21–3.25

Status: This issue has been fixed. The authUser command now correctly returns the authenticator (instance) serial number as CREDFLD_SERIAL_NO. Note that this attribute is not returned if a static password was used for the authentication.

Description: When a SOAP operation fails due to a database or ODBC connection issue, it correctly returns an error code (RET_FAILURE) whereas the status code indicates success (STAT_SUCCESS). Furthermore, the error stack in the SOAP response includes database/ODBC-specific error messages that can expose critical information to potential attackers.

Affects: OAS Authentication SDK 3.21–3.25

Status: This issue has been fixed. All SOAP operations now correctly return STAT_COMMS in case of database connection issues and don't include low-level database error messages in the SOAP response anymore.

Description: In some environments where more than one signature authenticator application is used, the authSignature command 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).

Affects: OAS Authentication SDK 3.21–3.25

Status: This issue has been fixed.

• The data field handling in the authSignature command was improved, any authenticator application that cannot process as many data fields as required by the request will be ignored.

• The attribute handling in the authUser command was changed to ignore Response-Only authenticator applications if the CREDFLD_CHALLENGE attribute is specified.

You can view the user documentation of most OneSpan products online already at https://docs.onespan.com/docs/, and we plan to shift exclusively to online documentation.

This means that PDF documentation will be completely removed in future major releases of OAS Authentication SDK (currently planned for 3.27).