HYPR Control Center sees an authenticator as a sensor that can be used to verify your identity - including fingerprint, camera, or audio sensors that read your fingerprint, face, eye, voice, or palm. An authenticator can also be a decentralized PIN, among other things. Alone or in combination, the rules surrounding required authentication methods comprise the policies that govern access to the Application in question.
This article discusses the default authenticators and policies provided so you can hit the ground running.
Then, in case you want to customize a little more, it covers creation, modification, and removal of both authenticators and the policies they combine to create.
FIDO Alliance Definition
A JSON data structure that allows a relying party to communicate to a FIDO Client the capabilities or specific authenticators that are allowed or disallowed for use in a given operation.
HYPR Control Center comes with two default, pre-installed authenticators:
- Native (TouchID or FaceID on iOS; Biometric prompt on Android)
- Personal Identification Number (PIN)
Likewise, each Application uses a default set of policies, which in turn are built by combining authenticators: registration, authentication, and for Web Applications, an authentication step-up policy.
If you're using the HYPR Mobile App, then no modification is required. Control Center will use these authenticators and policies by default.
defaultRegAction is the registration policy. The user is prompted with authenticator options during device registration. It typically includes all authenticators that will be used in all policies. The default registration policy is Native, then PIN. This means during registration the users will be asked to enroll with their Native ID. The second registration option is the PIN authenticator which offers an alternative authenticator when a Native ID is unavailable.
defaultAuthAction is the default authentication policy. The user is prompted with authenticator options (typically a subset of the authenticators that were registered with the Registration Policy) during authentication; It is by default only PIN.
completeMediumTransaction is the default authentication step-up policy. Used during step-up authentications (transactions); typically a subset of the authenticators that were registered with the Registration Policy. This policy is by default only Native.
While in production, disabling and enabling an authenticator will impact all users enrolled with that authenticator.
To manage authenticators:
- From the Control Center, first select the Application within the navigation panel for which the policy is intended; in the App Properties menu, select Policy Management.
Available Authenticators will show up under Authenticator Management. Click an icon to display relevant information about that authenticator in the sections below. In this example Native is selected; had PIN been selected, the title of the next section would be PIN Management.
- Manage enabled authenticators with ON/OFF toggle switches. Toggling the top-level switch will disable or enable the entire set of switches below to match; or you can use the individual toggles to choose specific AAIDs.
Once you are satisfied with authenticator behavior, you can start adding them to policies. For stronger authentication, combine more than one authenticator that will be required for access.
The Policy Management section allows you to add authenticators to a policy, or to manage existing authenticators within a policy. Each selected authenticator in a policy set is required to complete the authentication flow.
To view details about a policy, expand its entry by clicking the + to the right of the policy. It will turn into an x. Each Authenticator set will be displayed in numeric order. Click the x or expand a different entry to roll up the details.
HYPR Mobile SDK Users
Ensure the policies you create in the Control Center match the configuration in the HYPR SDKs.
To create a new policy, click Add Policy at the top right of the section.
Complete the Action Code Name and Description, then build a new policy. The example below shows that Native + PIN is required by the policy, and then just PIN if the first option fails. Click the '+' icon next to a set number to add a fresh entry; or if one is already present, clicking the + will an "AND" condition such that a HYPR Mobile App user is required to use a Step-up authentication that includes both authentication methods.
Adding more authenticator rows augments the policy to enable a different set of requirements in the event the first set cannot be satisfied by the device.
- Click Save, and HYPR Control Center will automatically return to the Policy Management main page.
Order of Operations
If the first set of authenticators are unavailable to the HYPR Mobile App, it will try the second set in the policy, and so on, up to a maximum of five sets.
With the desired Application selected, open Policy Management in the left navigation pane.
On the Policy Management page, in the Policy Management section, locate the policy to be deleted. Click the pencil icon to the right of the entry.
- The Edit Policy dialog opens; now it includes a trash can icon that was not present in the creation dialog.
- To edit, make the necessary changes and click Save
- To *delete*, click the **trash can icon**, then click **Yes, I'm Sure!** Your policy is now deleted.
Limit HYPR Mobile App users to a minimum version of the HYPR Mobile App, Android OS, or macOS. Users will be notified if they are in need of an upgrade, and will be unable to login after the cutoff date until they are upgraded to the required minimum version.
- Click Add Enforcement to impose version control on your HYPR users.
- Choose the Type, enter the Version, and pick the Block Authentication On date, then click Save when finished.
Your entry now displays in the main Policy Management page.
Use the pencil icon to edit the entry, and the trash can icon to remove it.
If the HYPR Mobile App or an OS version is lower than the Minimum Version stated in Version Control, a message will display explaining they require a higher version.
- The message for the HYPR Mobile App provides one option for Later and an Update option that opens the PlayStore/App Store page with the latest HYPR Mobile App Version for your device
- The message for the operating systems provides one option for Later and a Settings option that opens the device system settings to check for updates
Toggle this feature to give users with more than one authenticator the option to use a different authenticator if the first one fails.
This functionality requires the following:
- The policy definition must include two or more authenticators
- The user must have those two (or more) authenticators paired with HYPR
Once enabled, if an authentication attempt fails, the next method defined in the policy will initiate, following the order defined in Policy Management, until all available methods are exhausted.
Plan ahead for Fallback
Users with two accepted methods already paired will not need to refresh their pairs.
Users with only one method paired when Fallback Authenticators are enabled will need to unpair their existing account and pair all methods anew. We recommend encouraging users to complete two pairings prior to toggling the Allow Fallback Authenticators switch.
Updated 4 months ago