RSA Announces the Release of RSA Adaptive Authentication (On-Premise) 14.1

Document created by RSA Product Team Employee on Oct 20, 2020Last modified by RSA Product Team Employee on Nov 2, 2020
Version 15Show Document
  • View in full screen mode

Summary:

We are happy to announce the release of RSA Adaptive Authentication (On-Premise) 14.1, which includes these new features, enhancements, and changes.

Note: This release is only intended for customers who are upgrading from Adaptive Authentication (On-Premise) Version 14.0.2.1 to Adaptive Authentication (On-Premise) Version 14.1.

What's New in This Release

Adobe Flash Player End of Support

Adobe will end support of Flash Player on December 31, 2020. RSA recommends that customers disable the Flashed shared objects (FSO) from the device binding, and use the DeviceTokenCookie generated on the customer side or created by Adaptive Authentication.

Note: If the DeviceTokenCookie is deleted, you can use the DeviceRecovery mechanism to identify the device.

New feature support for PSD2 Exemptions to SCA

Adaptive Authentication (Cloud) 14.1 now includes support for second Payment Services Directive (PSD2) exemptions to Strong Customer Authentication (SCA), which are for payments and account access use cases. To support these changes, additional rules can be created in the Policy Management application that address all PSD2 exemptions in articles 10-16, and PSD2 data elements were added to the to the analyzeRequest message. For more information, see the new PSD2 Compliance appendix in the Back Office User Guide.

This feature enables creating these types of rules in the Policy Management application:

  • Rules to determine the number of days that have passed since the last time the user or 3rd Party Service accessed the user's account after successfully passing the Strong Customer Authentication (SCA) to determine whether a user needs to step up authentication to meet PSD2 requirements. These rules help to comply with PSD2 Article 10 regulation requirements. As a result, rule conditions (facts) have now been added to these rule condition (fact) categories: Account Details and Transaction Details. For more information, see Create Article 10 Compliant Rules in the Back Office User Guide.
  • Rules to indicate and challenge whether the amount of payments without a contact, such as payments through Apple Pay and Android Pay, that were performed by a 3rd party service using a customer's account are exceeding the number according to the PSD2 regulations, to understand if a user needs to increase authentication to meet the PSD2 Article 11 requirements.
    When creating rules for these contactless payments, there are two ways to configure these rules. You can either set up these rules for the payments performed by a specific 3rd party service or any 3rd party service. You must select one of these approaches and use the corresponding rule conditions (facts) in the Account Details rule conditions (facts) category. For more information, see Create Article 11 Compliant Rules in the Back Office User Guide.
  • Rules based on whether a payment transaction was made at an unattended transport terminal according to the PSD2 Article 12 regulation requirements. When creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type Others includes an UNATTENDED_TRANSPORT_TERMINAL option in the drop-down list. For more information, see Create Article 12 Compliant Rules and Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.
  • Rules indicating whether a transaction was made to a Trusted Beneficiary from a Trusted Beneficiaries list, or if a Trusted Beneficiary was added to the list. In addition, to be able to Allow/Challenge the transaction according to the PSD2 Article 13 requirements to ensure the changes were made by an authenticated user. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes additional options in the drop-down list. For more information, see Transaction Detail Rule Conditions (Facts) and Create Article 13 Compliant Rules in the Back Office User Guide.
  • Rules based on whether a transaction is a recurring payment transaction or a recurring payment list was updated by an authenticated user, according to PSD2 Article 14 regulation requirements. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes additional options in the drop-down list. For more information, see Create Article 14 Compliant Rules and Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.
  • Rules based on whether a payment transaction was made between accounts held by the same natural or legal person, to allow the transfer according to the PSD2 Article 15 regulation requirements. As a result, when creating a rule based on the Transaction Detail rule conditions (facts) category, the Transaction Type now includes a ME_TO_ME_PAYMENT option in the drop-down list. For more information, see Create Article 15 Compliant Rules and Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.
  • Rules indicating whether the payment transaction is a low-value transaction (remote electronic payment) type, and to handle these type of transactions according to the PSD2 Article 16 regulation requirements. As a result, rule conditions (facts) have now been added to the Transaction Detail rule conditions (facts) category. For more information, see Create Article 16 Compliant Rules and Transaction Detail Rule Conditions (Facts) in the Back Office User Guide.
  • New PSD2 data elements added to different request messages in the API

       These data elements were added to different request messages as detailed in this table:

Request MessageData ElementDescription
  • authenticateRequest
  • notifyRequest
isSca*

Indicates whether the Authentication Method being used is defined as a Strong Customer Authentication (SCA).

Note: When using the notifyRequest, you must send the isSca data element using the EXTRA_AUTH event type.

analyzeRequestisComingFromAggregatorIndicates whether the transaction data sent to the bank from a third party is being collected by an aggregator.
analyzeRequestthirdPartyId*Indicates the ID of the third party carrying out a transaction.
analyzeRequestthirdPartyName*Indicates the name of the third party carrying out a transaction.
analyzeRequesttokenIdIndicates the token ID.

*Note: Only the data elements with an asterisk beside them are relevant for PSD2 support.

   For more information on these data elements, see analyzeRequest Message, authenticateRequest Message, and notifyRequest Message in the API         Reference Guide. In addition, see PSD2 Data Elements in the Back Office User Guide.

  • New support for differentiating between PSD2 transaction payments and regular transaction payments in the API SOAPs and Policy Management application:
    • New parameter called transactionTypeOthers added to handle all PSD2 related transaction payment types in the transactionData structure: A new parameter called transactionTypeOthers has been added to the transactionData structure in the API. This value determines the different transaction payment types, which are related to creating PSD2 compliant rules. The available values in the transactionTypeOthers parameter were removed from the transferMediumType parameter, so that it would be easy to differentiate between PSD2 transaction payments and regular transaction payments in the API. For more information, see transactionTypeOthers in the API Reference Guide.
    • New rule condition (fact) called Transaction Type Others added to handle all PSD2 related transaction types in the Policy Management application: A new rule condition (fact) called Transaction Type Others has been added to the Transaction Details rule condition (fact) category in the Policy Management application. The values listed in this new Transaction Type Others rule condition should be used to create PSD2 compliant rules and were removed from the Transaction Type rule condition, where the values were previously listed. As a result, when creating rules that comply with PSD2 exemptions in articles 11-16, ensure that you use these value as listed in the Transaction Type Others rule condition. For more information, see Transaction Details Rule Conditions (Facts) in the Back Office User Guide.

New support for sending custom facts in notify requests that can be searched and viewed in the Case Management application

It is now possible to send custom facts in a notify request message with an Event Type set to EXTRA_AUTH, where this data is saved to the Adaptive Authentication database in the APP_EVENT_LOG_CUSTOM_FACT table, and can be accessed in the Case Management application using the existing functionality for custom facts.

The existing functionality in the Case Management application enables you to perform these tasks for activities containing these custom facts, which were sent in a notify request with the same session ID and Transaction ID:

  • Search for Custom Facts: In the Research Activities page, you can now filter for these custom facts using the existing Custom Fact filter. For more information, see Research Activities Filters in the Back Office User Guide.
  • View Custom Facts: In the Detailed Activity Information page, you can view these custom facts in the existing Custom Facts section. For more information, see Custom Facts Fields in the Back Office User Guide.

General Infrastructure Enhancements

The general infrastructure of Adaptive Authentication (On-Premise) has been improved, which includes database optimizations and monitoring enhancements.

Documentation updated cover pages, legal statements, and look and feel

The Adaptive Authentication (On-Premise) 14.1 documentation set has been updated to align with the RSA rebranding efforts to provide an updated look and feel. The documentation includes a number of formatting changes, such as a new cover page, legal statement, updated fonts, and new colors.

 

For additional documentation, downloads, and more, visit the RSA Adaptive Authentication page on RSA Link.

 

EOPS Policy:

RSA has a defined End of Primary Support policy associated with all major versions. Please refer to the Product Version Life Cycle for additional details.

Attachments

    Outcomes