Dynamic Policies

Description

Dynamic or "flexible" policies allow control over which authenticators are allowed for an operation on a per-operation basis. This feature enables the backend to control the authenticators which are offered to the end-user for a registration or authentication operation.

The added flexibility allows to cover scenarios where for example a user is forced to use the more secure biometric authenticator even though she has enrolled both the PIN and biometric authenticators.

Determining which policy to use is done by the relying party which is either a custom backend for registration operations or nevisAuth for authentication operations. If the relying party determines an operation to be of "high risk" requiring higher security, it may decide to restrict the available authenticators to the most secure biometric ones.

Prerequisites

• The nevisFIDO instance must have multiple policies configured.

Example

The following example shows how authentication can restrict the authenticators on the client side if two different backend services are involved. The first service will require restricting authentication to biometrics only whilst the second service will only allow PIN-based authentication. Although the example shows the authentication scenario, the same dynamic policy control can be used for registration and transaction confirmation scenarios.

1. Because the user wants to access health services, the custom backend starts an authentication and specifies the policy as being biometrics only.
2. The Nevis Mobile Authentication backend restricts the authentication request sent to the client allowing only registered biometric authenticators to be used.
3. The client is authenticated using his or her biometric credentials.
4. Another request issued by the end user to access a reporting service requires PIN authentication, so the custom backend starts another authentication and specifies the policy as being PIN only this time.
5. The Nevis Mobile Authentication backend restricts the authentication request sent to the client allowing only the registered PIN authenticator to be used.
6. The client is authenticated using his or her PIN credential.

Technical Flow

The technical flow shows the dynamic policy selection, it omits the specific details concerning the complete authentication flow and focuses on the parts where the dynamic policies are involved. This for simplification reasons only, the same flow is applicable for any other operation as well.

The selection of the policy can be done in multiple ways:

• static as an auth state string property
• provided as an inargs to the auth state which allows a previous auth state to set it as desired
• provided as JSON input to the auth state

This example uses a script state to set the inargs to a specific policy.

1. After an authentication flow has been started, a ScriptState determines that the authentication operation requires a heightened security and sets the inargs:policy variable of the FidoUafAuthState to only-biometric-authenticators.
2. The FidoUafAuthState evaluates the fidoUafProperty which has been set via inargs by the preceding auth state.
3. The GetUafRequest sent by nevisAuth to nevisFido contains the selected policy as part of the context object.
4. Based on the information provided in the GetUafRequest context, nevisFIDO will use the only-biometric-authenticators policy file to construct the ReturnUafRequest sent to the Access App.
5. The Access App filters the available authenticators the user registered beforehand based on the policy file and only returns biometric authenticators which can be used to perform the authentication.