Create FIDO policy risk rules

Introduction

You can create optional risk rules in a FIDO policy to evaluate the impact of various factors on a user's request to register or authenticate. A single rule looks at one risk signal, like device health. If a device issue is detected, the rule can deny the FIDO operation or allow it to succeed. A rule can qualify a success response with a risk score. So if a device health rule succeeds it could assign a risk score of 20.

The Auth Server executes matching risk rules until one of them returns a failure or they all succeed. If all the rules succeed, the Auth Server adds up the risk scores. You can define a threshold value in the policy. If the risk score total is greater than or equal to the threshold, the registration or authentication operation fails. Otherwise, the Auth Server returns a success response and the total risk score.

Risk rules differ from Adaptive Rules. Adaptive Rules are applied by the Auth Server before a user is authenticated to determine an authentication decision. A policy's risk rules are applied by the Auth Server after a user has successfully registered or authenticated with a FIDO method but before the final decision is sent back to the App SDK.

Supported risk signals

The following risk signals can be used in a risk rule:

• Device Health: Examines the device to see if it has been rooted, may also check if the OS was modified or running malware.
  
  A risk rule's condition checks if device health fails or if device health information is unavailable.
  
  The Auth Server determines device health using the jailbreak signal. A device's jailbreak status detects if it has been altered to provide root access. The App SDK must be configured to send this signal to the Auth Server. See Configuring Signal Generation in the Android or iOS App SDK Guides.

• Friendly fraud: Present if the user didn't utilize the correct biometric verification or the state of the biometric enrollments on the user’s device has changed. This signal is not applicable for fingerprint authenticators that support automatic key deletion.
  
  A risk rule's condition checks if friendly fraud is present.

• Shared Device: The number of users registered on the user’s device.
  
  A rule's condition specifies the maximum number of allowed registered users.

• Multiple Device: The number of different devices registered to the user.
  
  A rule's condition specifies the maximum number of registered devices that a user can have.

To see which signals are supported for which protocols and platforms, refer to Table 2 in Availability of Risk Signals used in Risk Rules.

Create a risk rule

1. In the Admin Console, login and, if needed, switch to the desired tenant. Navigate to Authentication > FIDO Policies.

2. On the Policy page, click Add Policy or select a policy to edit.

3. If you are adding a new policy, name your policy. In addition to letters and digits, only the following characters are allowed in a policy name: hyphen (-), forward slash (/), underscore (_) and space ( ).

4. On the Policy Details page, find the Risk Rules panel.

5. Click Add Rule and select a risk signal from the dropdown list.

6. A risk signal-specific dialog appears. After entering the rule name and specifying a value for the risk signal, select either Deny or Adjust Risk to. If you select Adjust Risk Score to, then select a risk score from the Select Risk dropdown.

7. You can optionally add a risk score threshold to your FIDO policy if your rules provide a risk score. In the Risk Threshold panel, toggle on Enable risk threshold evaluation and select the threshold value.

Configure the S3 Suite to support risk rules

Perform the configuration described in this section if you have rules that use device health or risk scores.

1. To support a device health rule, configure the App SDK to send the jailbreak signal needed by a device health risk rule. See Configuring Signal Generation in the Android or iOS App SDK Guides.

2. If you created rules with risk scores you must configure the Nok Nok API Server to handle the risk score. You have 2 choices:

   • Implement an API Server plugin: If your risk score interpretation requires sophisticated logic, access to data on one of your servers, or repeated interactions with your backend application server, then a plugin is your best option. For more information, see Create a plugin.

   • Modify the API Server's filter: By default, the API Server's filter prevents it from sending the risk score to your client app. See Response Filter Configuration to modify the filter. Choose this option if your risk score logic is unlikely to change. One drawback of this approach is that future changes to risk score logic will require that the user download an updated version of your app.

Customizing risk rules

You can create and process a custom risk signal. Contact support@noknok.com for more details.