How It Works
Prior to user enrollment, specific 2FA requirements must be applied within the PortalGuard configuration editor. The most commonly used 2FA requirement is Mobile SMS enrollment, as illustrated below. However, any of the supported 2FA methods may be configured, including multiple methods for a single user, group, or application. The only change in the processes depicted below will be in the initial two-factor enrollment prompt that the end-user is presented with, and the source of the required OTP during authentication.
The following series of steps and images outline User Enrollment and various Access Scenarios with Mobile Two-factor Authentication required.
Once two-factor authentication via Mobile SMS becomes an authentication requirement, the user will be prompted to enroll his or her mobile phone. PortalGuard provides flexibility around this process by allowing administrators to configure whether the enrollment will be forced or able to be postponed “x” number of times by the user. This increases the usability for users, giving them options around a process that many find intrusive and blocking.
The prompt will ask the user to input his or her mobile number, as well as select whether or not the device can receive SMS messages. If the user selects‘yes,’ an OTP will be delivered via SMS.
If the user selects‘no’, the OTP will be delivered via an automated phone call.
Once the number and one of the two options is selected, the user will be prompted to enter the OTP that was sent to his or her mobile phone in order to complete the enrollment.
Important Note:Phone enrollment can also be automated by importing the data from any current corporate datasource.
2FA Login Process Cloud/Web-based Application
The following process shows the standard Two-factor Authentication process when logging directly into a clour or web-based application. For a hands on example, visit the PortalGuard Sandbox.
Step 1: The PortalGuard login screen is presented when the user visits the application. This login screen can be fully customized to match the branding of your organization - creating a seamless end-user experience.
Step 2: Once the user enters his or her username and password and clicks login, an OTP is delivered to the registered mobile phone within 5-10 seconds. The user is then prompted to enter the OTP and click ‘Login.’
An Expired OTP: If a user attempts to use an expired OTP that was never used, he or she will be denied access and prompted to eithercancel the login process or request a valid OTP.
2FA Login Process VPN Using RADIUS
Most network security appliances allow VPN users to be authenticated using a variety of authentication mechanisms. A few common options are:
Reusing an OTP:If the user attempts to use an OTP that was already used - or in the case of a replay attack - PortalGuard will simply provide an ‘Authentication Failed’ strikeout dialogue.
User accounts defined locally on the appliance LDAP authentication
X.509 certificates RADIUS
The steps on the following pages show the two-factor authentication process when an end-user is logging into a cloud/web-based application using an SSL VPN connection by way of the RADIUS protocol.
RADIUS is one of various intenet standard, vendor-neutral network protocols, and was primarily designed to authenticate remote users for dial-up services. RADIUS is widely implemented by numerous network security vendors such as Cisco, Juniper, Citrix and Checkpoint, and has become an optimal choice for enabling 2FA for remote access users.
In the standard case, a network security appliance, firewall or Network Access Server (NAS) is the “RADIUS client” or “NAS client” and the PortalGuard server acts as the “RADIUS server”. The end-user only communicates directly with the NAS client in order to provide the necessary login credentials.
By definition, the NAS client communicates directly with the PortalGuard RADIUS server. As such, any authentication decisions made by PortalGuard are strictly enforced. This ensures a high level of both security and consistency.
Enabling multi-factor authentication can be as straightforward as enabling RADIUS on your network security appliance, pointing it to the PortalGuard server and adding a RADIUS client configuration in PortalGuard.
Important Note: The same RADIUS setup can often be used to authenticate remote users looking for SSL VPN via web browserand remote users with VPN software installed locally on their workstation. This helps to offer a high degree of consistency by reducing the need for user training and education.
Step 1: The user attempts to connect to the NAS/firewall using either a browser or VPN client software and is prompted to enter a username and password.
Step 2: TheNAS Communicates the credentials to the PortalGuard server using the RADIUS protocol.
Step 3: The PortalGuard server validates the user's credentials against its configured user repository (e.G. Active Directory, SQL, LDAP,etc.)
Step 4: The user repository returns a success or failure code indicating the fidelity of the username and password.
Step 5: PortalGuard replies to the RADIUS request with an Access-Challenge response that includes a custom message that should be displayed to the user and a random identifier (the‘state’)that the NAS will send back to PortalGuard in order to identitfy the same user session.
Step 6: The NAS displays the custom message requesting the user to enter the OTP that was sent to his or her mobile device.
Step 7: The user enters the OTP from the mobile device and submits it to the NAS.
Step 8: The NAS sends the OTP and state identifier to PortalGuard using RADIUS.
Step 9: The PortalGuard server replies to the RADIUS 2nd request with an Access-Acceptresponse.
Step 10: The NAS accepts the user's authentication and the VPN tunnel/session is established. The user is then able to access internal resources(e.g.“crm.acme.com”).