Multi-factor authentication

Use the MFA-Providers UI to configure Multi-factor authentication.

Multi-factor authentication is used by AppGate ZTNA to provide additional authentication. This can be used in three different ways within the product:

Device registration - MFA at sign in

Use the Identity Providers UI to configure MFA at sign in.

The registration of new devices (when valid credentials are presented) helps to prevent one of the most common forms of breach, namely when stolen credentials are used to sign in to a system from a new device.

There are three modes available:

1. Not required (automatically register all devices)

2. Once (MFA required to register all new devices)
   Required to register any new device, as long as the new device registration count has not been exceeded

3. Always (MFA required at every sign-in)
   Required whether a device has been registered or not, as long as the new device registration count has not been exceeded

Device registration works the same way in the case of the Portal however there are a couple of differences worthy of note:

• The cookie will only be saved if Remember me was checked on the sign-in screen.

• The cookie will be deleted if Sign out is used from the the menu (it is assumed the user is on a public computer and want to be forgotten).

The AppGate ZTNA system is designed to be able to run seamlessly in the background - only appearing 'on-demand' in response to user actions. This behavior includes features such as remembering your username and password, auto-starting the Client,  auto-renewal of the Claims token (signing the user in in the background), auto-launching of the browser when the SAML token expires, etc. None of these sit well with the Always option as this will prevent some of these automated operations causing the user to have to enter their MFA at unexpected times. Careful consideration therefore needs to be given to the required behavior of the overall system before selecting Always.

Once an MFA Provider is configured and provisioned for the user community then our system security best practice guide recommends the use of Once (MFA required to allow new devices).

If you are configuring MFA at sign in and also plan to use an MFA user interaction, then if you use the same user response claim suffix for both - you can avoid the user having to perform MFA twice over a short period of time.

User access - MFA user interaction

Use the Conditions UI to configure user access.

Unlike other security solutions where users may expect to have to provide multi-factor authentication at sign-in, AppGate ZTNA uses MFA in Conditions to provide real-time control over access to specific network resources. This is similar to banking applications which require additional authentication to make money transfers. As a result, a user might have to enter a multi-factor authentication only in the event of needing to access one particular resource. Conditions and the related user interactions give administrators flexibility to apply levels of security that are appropriate to the resources being protected. For example, standard services such as email can be made available to all authenticated users, while more sensitive resources can be protected through a Condition that requires additional authorization at the Gateway (eg. MFA or password) before the user is allowed access.

MFA user interactions are configured within Conditions.

For more information refer to user interactions.

Administrator access - MFA for Admins

Use the MFA for Admins UI to configure admin access.

Multi-factor authentication can be mandated for system administrators to gain access to the Admin UI. Exceptions can be added to allow API based access.

MFA for administrators is strongly recommended to control user access to the Admin UI even from the internal network. See System security - best practice for guidance on network access to port 8443.

For more information, refer to Admin user access.

How AppGate ZTNA supports different Multi-factor authentication

AppGate ZTNA can be configured to utilize either the built-in Default Providers or an external RADIUS Provider.

For details on how to configure Multi-factor authentication, refer to MFA Providers Configuration.

Default Time-Based OTP Provider

The built-in OTP provider works with most OATH time-based Authenticator apps.

Deployment and setup of the app on the user's mobile device is handled automatically the first time it needs to be used. When that happens, the user is guided through the download and setup process including seeding via QR code (or manual entry).

Initialization

OTP authentication requires the app and server to share a secret, which is called a seed. In AppGate ZTNA, a unique seed for the authenticator app is created as part of the initialization process:

1. The first time the user triggers an OTP user interaction (or logs in to the admin UI) that requires the default time-based OTP provider, the user will be prompted to set-up an authenticator app.

2. The Client displays a link - clicking on this opens another prompt with instructions for downloading and initializing the app.

3. Once the seed has been generated for the user's device, the admin UI will be updated to show that an OTP seed has been created for that user device but its status is flagged as "Unverified". When the user has demonstrated that the app has been successfully installed by entering a valid OTP, the Controller will remove the Unverified flag.

4. To list the status of OTP seeds, go to Default Time-Based OTP Provider seeds.

5. Once the app initialization has been completed successfully, the user will be prompted to enter a valid OTP.

6. When a valid OTP has been typed in the condition status will update the claims token and the status of the OTP seed become verified.

Initialization failure

If there has been a problem with initialization, the user can re-trigger the client to start the OTP setup process again:

• The user needs to sign out from the Client and log back in again, and then attempt to access the protected resource again

• This will trigger the Client to restart the OTP authenticator setup process

• The user will be prompted again to download and setup the app, and the OTP seed will be re-generated allowing the app to be initialized correctly

Reseeding

There may be other circumstances when the OTP app needs to be re-initialized: for example when the user gets a new mobile phone.

• Go to Default Time-Based OTP Provider seeds

• Delete the user's OTP seed

• When the user attempts to access the protected resource again, the OTP initialization process will be triggered again

Default FIDO2 Provider

FIDO2 is an evolving standard with a range of manufacturers and device types. These devices can require only touch to work, others touch and a PIN code, some more advanced ones include fingerprint recognition. The implementation in AppGate ZTNA is limited at this time:

• The general intent is only to support touch and fingerprint (as no UI interaction is required).

• On windows FIDO is actually handled by the operating system so more advanced UI interactive features are available including PIN code.

Many FIDO2 device manufacturers have companion apps which are available from their web sites or desktop app stores.These can be used to identify device types, version information as well as to configure options such as the use of a pin code. The FIDO2 devices might work out of the box or might require options such as PIN code disabling BEFORE attempting to use with AppGate ZTNA.

FIDO2 devices can be separately enabled for different apps (such as AppGate ZTNA). This should mean it is possible to use the same FIDO2 device for user device authentication (see https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/20/sign-in-to-your-microsoft-account-without-a-password-using-windows-hello-or-a-security-key/) and for a user interaction using AppGate ZTNA.

NOTE

Not all use cases are supported in the AppGate ZTNA system at this time - it is not possible to use FIDO2 for Admin UI access.

Initialization

Once set up correctly a new FIDO2 device simply needs to be plugged into the USB port when requested. After it is initialized, touching the FIDO2 device is the only response the user needs to perform when a user interaction is triggered.

Initialization happens automatically the first time the FIDO device is used with AppGate ZTNA. The FIDO key creates a new credential key pair; the FIDO device retains the private key; the public key is signed by the attestation key pair key (which is model specific NOT device specific) and sent to the AppGate ZTNA Controller. Authentication is achieved by the FIDO key sending a signed (using the private key) response to any subsequent challenge sent by AppGate ZTNA Controller. The devices private keys can be used only after they are unlocked locally by the user. The local unlock is accomplished by the user (inserting the FIDO2 device and) touching the button.

The Controller associates the public key to the user so they would need THAT key in future as it now contains the matching private key. The Controller does not care about what key is used only that there is a key pair for that user. Because the key is not necessarily bound to a user it would be possible for 2 users to share a key. This is an advantage in the case of an AppGate ZTNA user who has a local account and an LDAP account which would look like 2 different users to the system. In this case the user could use the same FIDO key for both accounts - the authentications would remain unique, each account having had a unique key pair generated at initialization time.

This also means you can use the same key multiple times, so you can have Google, O365, and maybe a couple of AppGate ZTNA instances all tied to the one key. One of the FIDO principals is of user privacy so the attestation signing certificate is unique to a device model, not an individual device. If every device had a different attestation certificate, that attestation certificate can be used to track and identify the individual across the different services where the FIDO key is used.

Re-Initializing

There may be circumstances when the FIDO2 device needs to be re-initialized.

• Go to FIDO2 Provider Devices

• Delete the user's FIDO2 device

• When the user attempts to access the protected resource again, the initialization process will be triggered again

RADIUS Providers

There are numerous different RADIUS providers with many different types of user interaction. AppGate ZTNA provides support for a number of these (but not all) using the standard RADIUS protocol. Below is an explanation of the three different modes that are supported and how they are used. Even though the AppGate ZTNA system appears to only have these three modes there is still a lot of flexibility in how these are configured so the effect  multiplies up in terms of the number of different overall RADIUS implementations supported.

Authentication modes

AppGate ZTNA Preemptive OTP

This mode is typically used when the user has a token or app which presents the OTP ahead of beginning any RADIUS interaction. This would often involve the user entering all their credentials at one time and then starting the authentication process.

However there is no constraint on what can be entered into the Client when prompted for additional authentication. So the user could enter some recognized term (by the RADIUS server) which might then initiate a user interaction such as having to perform some additional step using a phone app.

RADIUS Server OTP

This mode can be used for what many RADIUS providers refer to as Push OTP. Typically the RADIUS Provider will have an app on the user's phone which the RADIUS server will communicate with. These apps can perform various different forms of additional authentication such as pushing a button, entering an OTP, performing a fingerprint scan etc. Once the RADIUS server is happy with the user's response then the Access-Accept message is sent.

AppGate ZTNA Client interaction using RADIUS challenge-request method  

This mode is the more traditional challenge based RADIUS use case. Here the AppGate ZTNA Client provides the user interaction on behalf of the RADIUS server. The only interaction types supported at this time is OTP whereby the user typically has to enter a 4 or 6 digit code.  

When using this mode the Client will present the user with a message which will come from the AppGate ZTNA system itself or use the reply-message (24) from the access-challenge (4) message from the RADIUS server.

In all three cases if a RADIUS Access-Reject (3) message is received it may be accompanied by a Reply-Message (18). If this is present it will be passed to the Client and will be written to the Client log file.

Multiple RADIUS MFA Providers

You may want to configure your system to provide more than one method of additional authentication. The AppGate ZTNA system can easily support this with multiple MFA Providers.

If you want to use multiple RADIUS providers the normal way of doing this would be to configure the RADIUS server to have two instances of the AppGate ZTNA system. Configure the second instance (often referred to as RADIUS Clients) with an alternative authentication methods and also set the port differently (from 1812). Then, configure the AppGate ZTNA system twice, once for each RADIUS client, remembering to match the port numbers to those used earlier. This will also work with two distinct RADIUS servers.

This configuration is not designed to provide support for HA working - the two MFA providers would appear to the admin/user as two distinct types of MFA user interaction.

To understand more about HA working (load balancing and fail-over) refer to Configure Multi-factor authentication.

Using an IdP as an MFA Provider

The Password user interaction provides an alternative means of implementing MFA in AppGate ZTNA. This can be as simple as re-entering the same password that was used at sign in at a specific time - as is often used in Internet banking. Clearly for true MFA a different IdP should be specified (requiring a different password) when configuring the user interaction.

NOTE

The user name related to the MFA IdP must match the one used with the sign-in IdP.

When a SAML IdP is used then it becomes possible to utilize the password user interaction for a range of alternative MFA methods. This means that certain SAML IdPs such as Azure MFA, can also be used as an MFA provider in the AppGate ZTNA system.

To achieve this you need to:

• Create a secondary SAML instance making sure it is linked to the same user name as the primary configuration (which is used for sign-in).

• Configure this instance to to use some sort of MFA only mode such as using a push message to a mobile phone.

• Add another IdP instance in AppGate ZTNA and link it to the secondary SAML IdP.

• When setting up the user interaction within a Condition pick this IdP.

When the user interaction is required; some sort of strong MFA request will issued via the browser. When this is fulfilled by the user, the SAML IdP will return the usual authentication response which the AppGate ZTNA system will accept as a valid password user interaction.