# Multi-Factor Authentication - Link: https://www.agilicus.com/anyx-guide/multi-factor-authentication-cfg/ - Published: 2024-05-14T00:24:54+00:00 - Author: Don Bowman 1. [Home](https://www.agilicus.com/) 2. Multi-Factor Authentication ![multi-factor-auth](https://www.agilicus.com/www/8041b3de-multi-factor-auth.svg) I AM. I HAVE. I KNOW --- ## Multi-Factor Authentication Enable this best-practice on any application, for any user, regardless of authentication identity provider. [CONTACT](https://www.agilicus.com/contact-us/) ## Multi-Factor Authentication Configuration See [background](https://www.agilicus.com/multi-factor-authentication/) on Multi- Factor Authentication. In this implementaiton of Multi-Factor Authentication, the user is prompted to authenticate to their upstream identity provider, and, then, a multi-factor challenge is provided via web. State can be kept in a secure cookie on the ‘auth.DOMAIN’ endpoint. This can allow single-sign-on with multi-factor as well as only requiring a 2nd factor over some time interval. ### Supported Methods: WebAuthn (Passkey, USB Authenticator, FIDO U2F, …) The Web Authentication ([WebAuthn](https://www.w3.org/TR/webauthn-2/)) standard is the current best practice. It allows seamless integration of platform-specific features (biometric, TPM) with external [U2F](https://en.wikipedia.org/wiki/Universal_2nd_Factor) and [CTAP](https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol) devices. Browsers and versions supporting WebAuthn can be seen [here](https://caniuse.com/?search=webauthn). WebAuthn is designed to be privacy preserving, no information on the user or device is shared with the network. This includes biometrics. [⌊8e1b3b16-image⌉⌊8e1b3b16-image⌉[ ### Supported Methods: TOTP (Time based challenge app) A time-based one-time password ([TOTP](https://en.wikipedia.org/wiki/Time-based_One-Time_Password)) is a universal standard, implemented by many applications (including [Authy](https://authy.com/), [Google Authenticator](https://en.wikipedia.org/wiki/Google_Authenticator)). TOTP is private (there is no network communication flow) and works even without a graphical or browser flow. Agilicus’ implementation works with all TOTP-supporting applications, however, we recommend Authy. Our strategy is to not supply “yet another” TOTP application. Instead, we recommend users use a common one across all websites, including ours. ### Web Push Web Push uses a network authentication profile called [VAPID](https://datatracker.ietf.org/doc/html/rfc8292). This is designed to be entirely private: there is no way to identify the user or device receiving the push. In the Web Push model, the user’s browser (whether open or not) will receive a ‘push’ “WAS THIS YOU” message when you try to login, even on another device. Web Push is secure and convenient. However, the major downside is Apple, which does not support push methods. There is a petition [requesting](https://www.change.org/p/tim-cook-apple-inc-implement-web-push-notifications-on-ios-devices) support. [⌊7ad4854b-image⌉⌊7ad4854b-image⌉[ ## Authentication Rules Authentication Rules are a type of Conditional Access. They are logically part of the authentication flow, after he user has proven identity. These rules can augment the logic with things like: * has provided multi-factor authentication * is in / not in IP ranges * application properties * user properties * device properties The system has a set of policy presets. These operate like macros, overriding the current rules and then leaving them free to configure. See [more information](https://www.agilicus.com/anyx-guide/authentication-rules/) on Authentication Rules. Three presets are provided: ### Default You should choose this option for strong security and convenience for your users. Using a single identity source of truth among many applications enables maximal ease of use, while enabling multi-factor-authentication ensures that anyone without physical access to their device(s) cannot compromise the account. You will always be able to revoke a user’s access at any time and audit their usage of any applications or services. Details: Multi-factor authentication can be enabled per client, by default it will follow a user’s preference A user’s session is shared between apps unless that app’s client has Single Sign-On set to ‘never’ A user’s session lasts up to 7 days Multi factor authentication must be used to log in after every 30 days if a multi-factor authentication method has been configured ### Permissive You should choose this option if the data you need to get to your employees needs to be protected, but is not of a particularly sensitive nature. This option enables low barrier to entry to get as many users as possible onto the system with as little administrative overhead as possible. You will always be able to revoke a user’s access at any time and audit their usage of any applications or services. Details: Multi-factor authentication can be enabled per client, by default it will follow a user’s preference. A user’s session is shared between apps unless that app’s client has Single Sign-On set to ‘never’ A user’s session lasts up to 14 days Multi factor authentication must be used to log in after every 30 days if enabled ### Strict You should choose this option if you need the minimum ‘blast’ radius from a compromised device. By reducing the sharing of sessions between applications, minimizing multi- factor authentication duration and requiring frequent logins you can guarantee that in the event an employee’s device is compromised they cannot access anything other than what the employee is currently logged into. You will always be able to revoke a user’s access at any time and audit their usage of any applications or services. Details: Multi-factor authentication can be enabled per client, by default it will follow a user’s preference A user’s session is not shared between apps unless that app’s client has Single Sign-On set to ‘always’ A user’s session lasts at most 1 day Multi factor authentication must be used to log in every 7 days ## Trust On First Use Agilicus recommends a ‘Trust On First Use’ method of self-enrolment. In this model, a user is forced to setup their second-factor on the next sign-in, with a maximum deadline. The deadline is set organisation wide, and is the delta from when the user is created until when they must have successfully demonstrated a 2nd-factor setup. [⌊1822a2aa-image⌉⌊1822a2aa-image⌉[ ## End-User Setup (Profile) [⌊99849e39-image⌉⌊99849e39-image⌉[ The end user may manually navigate to “Profile” (via https://profile.DOMAIN). They may also install it as a Progressive Web App (PWA), making it appear as a mobile- native application. In the Profile, the user may setup whichever multi-factor methods their organisation has chosen to support. if trust on first use is used. the user will be forced here on their first login within the enrolment period. ## Diagnostics and User Audit ![48efb62c-image](https://www.agilicus.com/www/48efb62c-image.png) We can see which users have multi-factor setup in the ‘Users’ screen (via the shield). We can also filter to show only user with/without multi-factor authentication enabled. The “RESET” users option will unset the multi-factor setup & preferences of a user. We can see the multi-factor sessions and preferences (as well as all other audit information) of a given user on the audits screen. Here too we can reset the trust- on-first-use timeline. ![cf4f4220-image](https://www.agilicus.com/www/cf4f4220-image.png) ## Requiring multi-factor authentication Normally, a user must periodically present their second factor when authenticating only if they have it enabled. That said, you can configure the policy to require a set of users to have a second factor method configured. If such a user tries to log in when they do have not have a second factor method configured, they will either be asked to enrol one, if they are within the enrolment deadline, or they will be denied access. You can configure this setting in one of two ways. If you have not yet customised your authentication policy, you can apply one of the presets. Choose the preset to apply, then select the groups for which you want to force multi-factor authentication in the “Always require multi factor authentication for groups” section. ![image](https://www.agilicus.com/www/395f2a25-image-1024x487.png) If the group you want does not exist, [create](https://www.agilicus.com/anyx-guide/groups/) it first. If you have customised the policy, you can either edit the existing rule which controls this behaviour, or create a new one. Under the “default multi-factor authentication rules” group, select the “Group Requires Multifactor” rule, then configure its condition (via the actions menu). ![image](https://www.agilicus.com/www/d08bdb3f-image-1024x456.png) Choose “Configure condition details”, then select the desired groups in the “Values” chiplist. Do not change the operator. Once you have chosen the groups, navigate to “Apply” and click “Add”. ![image](https://www.agilicus.com/www/8c8ebfbb-image-1024x487.png) If this rule does not exist, you will need to create a new one in the “default multi- factor authentication rules” group. First, click “Add rule”, then select the newly created, blank rule. Change its name to “Group Requires Multi-factor”: ![image](https://www.agilicus.com/www/de1c6954-image-1024x487.png) Set its Action to “Require Second Factor”. ![image](https://www.agilicus.com/www/b4095f94-image-1024x487.png) Then add a new condition. Set its type to “Object attribute” with field “user member of id. ![image](https://www.agilicus.com/www/51841c6f-image-1024x487.png) Move next to “Configure condition details”, where you will choose the “in” operator. Select the desired groups under “Values”. ![image](https://www.agilicus.com/www/081241bb-image-1024x487.png) Move next to Apply to add the condition. Once you done so, the policy will be updated, and users in the configured groups will be forced to provide a second factor. ![image](https://www.agilicus.com/www/36fba167-image-1024x487.png) ## Multi-Factor Authentication Frequency Similar to an authentication [session](https://www.agilicus.com/anyx-guide/authentication-rules/#authentication-session), a user’s proof of their second factor is only valid for a configurable amount of time. This configuration is part of the authentication policy. The duration for how long the second factor is valid is expressed in seconds. It can be configured either by applying a new preset, or by editing the appropriate authentication rule. To apply a preset, choose the desired one from the “Authentication/Authentication Policy” page, then choose the time interval. ![image](https://www.agilicus.com/www/55319a2d-image-1024x487.png) In this example, users will be asked to present their second factor every 2592000 seconds (30 days). Choose your desired value, then hit apply. To configure the existing policy, open the “default multi-factor authentication rules” group, and choose the “User has succesfully provided a second factor within time window” rule. ![image](https://www.agilicus.com/www/bcea7712-image-1024x487.png) Edit the value by selecting “Configure Condition” from the actions menu. ![image](https://www.agilicus.com/www/e1d226dd-image-1024x487.png) Then apply the change by select “Add”. ![image](https://www.agilicus.com/www/6da7a683-image-1024x487.png)