I AM. I HAVE. I KNOW
Multi-Factor Authentication
Enable this best-practice on any application, for any user, regardless of authentication identity provider.
Multi-Factor Authentication Configuration
See background 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) standard is the current best practice. It allows seamless integration of platform-specific features (biometric, TPM) with external U2F and CTAP devices.
Browsers and versions supporting WebAuthn can be seen here.
WebAuthn is designed to be privacy preserving, no information on the user or device is shared with the network. This includes biometrics.
![Multi-Factor Authentication 2 8e1b3b16 image](https://www.agilicus.com/www/8e1b3b16-image-1024x247.png)
Supported Methods: TOTP (Time based challenge app)
A time-based one-time password (TOTP) is a universal standard, implemented by many applications (including Authy, 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. 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 support.
![Multi-Factor Authentication 3 7ad4854b image](https://www.agilicus.com/www/7ad4854b-image-1024x321.png)
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:
Default
Permissive
Strict
Trust On First Use
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.
![Multi-Factor Authentication 4 1822a2aa image](https://www.agilicus.com/www/1822a2aa-image-1024x373.png)
End-User Setup (Profile)
![Multi-Factor Authentication 5 99849e39 image](https://www.agilicus.com/www/99849e39-image-766x1024.png)
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
![Multi-Factor Authentication 6 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.
![Multi-Factor Authentication 7 cf4f4220 image](https://www.agilicus.com/www/cf4f4220-image.png)