Policy Mechanism

1. Introduction

A policy is a deliberate system of principles to guide decisions and achieve rational outcomes. Policies are linked to functionalities in our solution and will have contextualised meaning from case to case. Veridium can determine what authenticators are available for enrolment based on user groups and policies.

2. Policy definition

2.1 Integrating policies into Veridium Core

Policy objects are naturally attached to groups. ActiveDirectory does this as well. Since administrators are already familiar with this practice we want to make VeridiumID configuration similar and take advantage of group membership from AD as well. Policies attached to these groups will determine how the user will interact with our system.

2.2 Policy structure

The policy object is going to be built based on a policy template. A policy template is defined by a set of parameters that are going to be set for a particular policy object. An example of policy template is:

• totpEnabled

• has4FBiometry

• hasTouchIdBiometry

• hasFaceBiometry

• fidoEnabled

• smsEnabled

• externalToken

Inside a policy object, each of the above parameters can have one of the values:

[TRUE, FALSE, NOT_SET].

3. Policy aggregation.

3.1 Profile Group Policy

In an ideal case, and to keep things clear and simple, a profile (user in a given context) should have only one policy object assigned. But since groups can change at runtime, when computing policies based on group membership multiple policies may match at the same time. To decide what are the parameter values that determine how features are applied in the given context, policies may be aggregated into one.

The aggregation algorithm chosen for our implementation has one rule: for each parameter we compute the set (list with unique elements) of values contained in the user’s policies and we choose the left most value in the following array: [TRUE, FALSE, NOT_SET] present in the set.

Example:

• One of the policy objects has totpEnabled FALSE and other has OPTIONAL => aggregated value for totpEnabled is FALSE.

  • (FALSE, OPTIONAL) → FALSE

• One of the policy objects has totpEnabled TRUE => TRUE (because it is the value to the left part of the array, so other policy values cannot change the final aggregated value)

  • (TRUE, *) → TRUE

Anything set at a group policy level will overwrite the settings in the Global Policy.
See next section “Global Policy”

3.2 Global Policy

Each policy template will have a global policy object. The global policy object represents a default policy that is applied for any profile in case the groups it is member of do not have any policies attached. If the user is part of at least one group with attached policy then global policies are overridden and are not taken into account when computing the final aggregated policy. These global policies are not introduced by the admin, the admin has only the option to edit them.

The global policies are introduced when the <API_URL>/websecadmin/rest/setup/setupGlobalPolicies endpoint is called

The global policies are used for ease of configuration (not to miss a particular set of users because of missconfiguration) and to give a baseline on how normal (most of the users) will interact with the system. Also, for backwards compatibility between a new server and an older mobile application version, the biometries for older mobile applications are returned from the global policies (they are removed from the integration).

3.3 Example for configuring an ordinary system

If there is a majority of users that are expected to interact in a particular way with VeridiumID, we can setup the Global Policy accordingly. E.g. If we want most of the users to login using TouchID, we can set hasTouchIdBiometry = TRUE in the Global Policy and everything else on FALSE

For each exceptional group of users we can define policies:

1. Users that should not use biometry and use TOTP instead (part of the AD group NonBiometric): create a policy (TotpAlternative) with totpEnabled = TRUE and everything else set on FALSE.

2. Users that cannot use / lost their phone (part of the AD group LostPhone): create a policy (EmergencyFallback) with externalToken = TRUE, totpEnabled = OPTIONAL and hasTouchIdBiometry = OPTIONAL (OPTIONAL is for the case they recover the phone) and everything else set on FALSE.

3. users that don’t have smartphones (part of AD group NoSmartphone): create a policy (AlternativeAuthenticators) with fidoEnabled = TRUE, smsEnabled = TRUE and everything else set on FALSE.

 By attaching the policy on discriminating groups the desired behaviour can be achieved. If the user is part of two groups, user can have multiple choices to to authenticate. This is useful for temporary making a user part of a group that relaxes the authentication constraints or offers an alternative to the main authentication method. E.g. if a user that is normally part of the NonBiometric group lost / forgot his phone. AD Admin can add him temporarily to the LostPhone group so he can use the Gemalto Token to login. So the user has both NonBiometric and LostPhone group membership, making both TotpAlternative and EmergencyFallback policies applicable, so he will be allowed to either use TOTP or EXTERNAL_TOKEN to login.

4. Administration

The Administration dashboard offers CRUD operations on policies based on some predefined templates and assign them to VeridiumID groups. The sidemenu section where the policy administration is handled is Orchestrator - Policy.

Once the policy is defined, then it can be associated to a group. Please navigate to a group details page and notice the new field Policies. All defined policies are available to associate to groups.

The policy system determines what are the methods that a user can use to authenticate. It controls, based on the profile groups what combination of biometric checks should a user pass in order to be authenticated or what alternative authentication methods he has access to.