Skip to main content

Policies

A FIDO UAF policy decides which authenticators a user may use for a mobile authentication operation. It is how you express requirements such as allowing biometrics only, or accepting an application PIN.

Policies are security relevant in both directions. A policy that is too permissive weakens the assurance you get from mobile authentication. A policy that is too strict, or that names an authenticator the deployed application does not implement, can leave users unable to register or authenticate at all.

For the policy format, the attestation extensions and a large set of worked examples, see Policy configuration examples. This page covers how to configure and select policies in nevisAdmin 4.

Four different things called policy​

The nevisFIDO UAF Instance pattern has four settings with Policy or Policies in the name. Only the first one selects authenticators.

SettingWhat it is
PoliciesThe FIDO UAF policy files. This is the subject of this page.
FIDO UAF Credential PolicyThe extId of the nevisIDM credential policy applied to FIDO UAF credentials.
Dispatch Target PolicyThe extId of the nevisIDM credential policy applied to Dispatch Target Generic credentials.
iOS App Attestation PolicyThe extId of the nevisIDM credential policy applied to iOS App Attestation Generic credentials.

The last three are nevisIDM credential policies. They govern the lifecycle of the credential records in nevisIDM, not which authenticator the user may present.

Credential policy changes are not retroactive

Changing any of the three nevisIDM credential policy settings does not update credentials that already exist. Only credentials created afterwards use the new policy. Plan accordingly if you tighten a policy on a system that is already in production.

Configuring the policy files​

Upload your policy files in the Policies field of the nevisFIDO UAF Instance pattern.

  • Each file contains exactly one policy, as a single JSON object.
  • The file name without the .json suffix is the policy name that you refer to elsewhere.
  • default.json is mandatory. It is used whenever an operation does not name a policy.

The pattern ships with default, pin_only, biometrics_only and password_only. Use them as they are, or as a starting point for your own.

Policies and metadata belong together​

A policy allows or disallows authenticators by AAID, the identifier of an authenticator implementation. The Metadata field supplies the corresponding authenticator metadata.

nevisFIDO ignores any authenticator that has no metadata entry, and blocks all operations for it. If you deploy a custom application built on the Nevis Mobile Authentication SDK, or a customized white label Access App, update the metadata as well as the policy.

The AAIDs used by the Nevis authenticators are listed with the metadata in the Policy configuration examples. Android authenticators use the range F1D0#000x and iOS authenticators the range F1D0#100x.

Selecting a policy for an operation​

A policy applies per operation, not globally. There are two ways to choose one.

Statically, in the pattern​

The Out-of-band Mobile Authentication, Usernameless Out-of-band Mobile Authentication and Out-of-band Mobile Onboarding patterns each have a Policy field. Enter the name of a policy that the assigned nevisFIDO instance provides. The default is default.

The field also accepts a nevisAuth or EL expression, so the policy can be derived from request or session data without any change on the relying party side.

Dynamically, from the relying party​

An application that calls the nevisFIDO services can name the policy per request, by setting it in the context of the GetUafRequest:

context: JSON.stringify({username: userExtId, policy: "pin_only"})

nevisFIDO then uses the policy file of that name. This is what the documentation calls dynamic or flexible policies, and it lets one deployment serve a low-value service with a PIN while requiring biometrics for a high-value one.

Dynamic selection is not a different policy format. It selects one of the same files you configured in the Policies field. For the full flow, see Dynamic policies.

Matching the policy to the deployed application​

Not every authenticator exists in every application

If a policy names an authenticator that the installed application does not implement, that authenticator is simply not offered. To the user this looks like nothing happening, or like no suitable authentication method being available, which is hard to diagnose from the server side.

Device Passcode and Password are supported by the Nevis Mobile Authentication SDK but not by the Nevis Access App. A policy that permits only those two therefore fails for every Access App user.

Check your policy against the application you actually deploy:

Also keep in mind that the SDK registers at most one authenticator of each type per user, and that biometric authenticators are only available on devices that have the corresponding hardware. Always leave a usable fallback in the policy, or handle the case where no authenticator matches.