Configure Feedback for External Applications

The ActivID AS push-based authentication solution provides different methods for client applications to receive feedback regarding the end user’s actions:

Feedback Method Supported Feedback
  Registration

Action or Logon
(approve/decline)
1: CIBA HTTP notifications Enable Registration Feedback using Asynchronous HTTP Callback Enable Validation Feedback using CIBA Notifications
2: JMS notifications Enable Registration Feedback using JMS (Java Message Service) Notifications Enable Validation Feedback using JMS Notifications

Choosing the Notification Method

By default, it is recommended that you use Client-Initiated Backchannel Authentication (CIBA) notifications because the setup is easier and involves less network constraints. Typically, Java Messaging Service (JMS) requires that you are able to tune the firewall configuration to enable specific ports – which might not be possible, or involve delays due to organizational processes.

This is why CIBA feedback is recommended, for example, when interfacing the ActivID AS server deployed on-premise and with applications deployed in a public cloud.

Lastly, the CIBA feedback for registration setup is straight forward as it simply requires an update to the Issuance Request and minimal configuration in ActivID AS.

On the other hand, JMS feedback (when configured with persistent messaging) can provide guaranteed message delivery (once-and-only-once), while CIBA feedback involves a risk of lost notifications if there is a network shortage or if the web service called by the notification callback is down.

The CIBA and JMS methods for action or logon workflows are detailed below.

Method 1: Using CIBA HTTP Notifications (Recommended)

The ActivID AS calls the client application via HTTP POST notifications on a pre-registered RESTful API endpoint.

  1. User authenticates to the client application portal.
  2. Client application sends a push authentication request to the application server.
  3. Client application server sends CIBA authentication request to ActivID AS.
  4. ActivID AS sends a push logon request to the user’s mobile device via a notification hub.
  5. Hub forwards the push logon request to HID Approve on the user’s mobile device.
  6. User’s approves the logon request using HID Approve on his mobile device.
  7. HID Approve sends the user’s push response to ActivID AS.
  8. ActivID AS sends feedback of the user’s approval to the client application using CIBA notification.
  9. Client application grants the user access to the portal.

Method 2: Using JMS Notifications

The ActivID AS sends feedback client applications by subscribing to a topic on a Message Queue (MQ) solution.

  1. User authenticates to the client application portal.

  1. Client application sends push authentication request to application server.

  2. Client application server sends authentication request to ActivID AS.

  3. ActivID AS sends push logon request to user’s mobile device via notification hub.

  4. Hub forwards the push logon request to HID Approve on the user’s mobile device.

  5. User’s approves the logon request using HID Approve on his mobile device.

  6. HID Approve sends user’s push response to ActivID AS.

  7. ActivID AS sends feedback of user’s approval to client application using JMS notification.

  8. Client application grants the user access to the portal.

The configuration uses the following internal components:

  • An audit adapter to send a feedback regarding the registration of mobile devices.

  • A process adapter to send a feedback regarding the validation of operations (Logon or Action).

Note: The adapters described in this section exist by default in the dataset so you do not need to create them. You can edit the adapter configuration to specify custom channels or authentication policies.

Topics in this section: