Configuration overview

Prior to implementing Adaptive Authentication in your client app, you need to configure the Auth Server by translating your company's security and fraud detection procedures into Adaptive Rules and FIDO Policies. Keep in mind that Adaptive Rulesets, rules, and their supporting data objects are tenant-specific.

1. Design your Adaptive Rules: Write down your criteria and decisions in the form of if-then statements. Group related rules into rulesets. For example, you could group together transaction authentication rules for EU countries in one ruleset. By the end of this design session, you should have identified the signals, context data, user history, authentication methods, and FIDO authenticators you need.

2. Create your Adaptive Rulesets and supporting data: Use the Digipass S3 Server Admin Console to do the following:

   1. Define data and authenticator lists:

      1. Location-related lists: Rules can check if a user is located within or outside a set of countries or a set of geofences. A geofence is a custom geographic region that you create using the RFC 7946 JSON format. You can create lists of countries or geofences that can be referenced in a rule's condition.

      2. Network-related lists: Rules can check to see if a user's IP address or WiFi network is or is not present in a list of IP addresses or WiFi networks, respectively.

      3. Device Model lists: You can create lists of device models for different purposes. For example, you could create a device model list called VulnerableDevices and use that to deny authentication for sign in. You could create a list of ultra-secure devices and only allow users to authenticate transactions if they are using one of those devices.

      4. FIDO UAF authenticator groups: If a rule triggers authentication, you can specify that the user must use a FIDO UAF authenticator from a list that your organization has approved. You can create different lists of authenticators, for example, based on the device OS or manufacturer. These lists are used by FIDO policies.

   2. Define FIDO policies. If an Adaptive Rule's Action is Trigger Authentication, then you can list any combination of authentication methods in authentication sequences. FIDO authentication methods listed in those sequences must be contained in a FIDO policy. FIDO policies primarily identify valid authenticators that a user can utilize.

   3. Configure OTP and other non-FIDO authentication methods. The Auth Server ships with a dummy configuration for OTP and Photo ID. If you don't plan to use these methods, then delete them. Otherwise, there is additional configuration required.

   4. Define Adaptive Rulesets and rules. Use the Adaptive Rule editor to create the rule's condition, specify the action, define authentication sequences, and, optionally define claims.

3. Specify an app's default Adaptive Ruleset. If it makes sense for your app to use a default ruleset for adaptive authentication, you can easily set this up.

4. Verify that IP address is sent and a FIDO 3DS blob is returned. If you have a rule that uses IP Address in its condition, the IP Address Extractor plugin must be active. If you have a rule that returns an EMV 3DS FIDO blob, the EMV 3DS Generator plugin must be active.

The client app developer is responsible for the following tasks:

1. Configuring the App SDK to generate and send signals.

2. Passing in context data when they call the App SDK's Adaptive Authentication method.

For more information about the client app, see the Developer Guide for your platform.