Implementing Multi-Factor Authentication
on EFT Server

#10 TOP TIP on Globalscape EFT Server

By Michelle | Jun 30, 2017 | EFT, Top Tips

Multi-factor authentication is defined as verifying a user’s identity based on at least two of the following criteria:

Something you have
Something you are
Something you know

In most people’s minds, two factor authentication is a RSA SecureID type key, with a code which changes every 30 seconds. This, in addition to your password, would certainly count as two factor authentication (2FA). It would be something you know (your password) and something you have (the SecureID Token).

Using EFT features to implement a two factor authentication

Not every organisation has a solution similar to the SecureID system. But don’t worry, with an EFT server you can still implement a two factor authentication (2FA) without investing in additional software. This is due to some of the built in features.

FTPS and SFTP connections

FTPS and SFTP connections can be protected using “private key authentication” and by restricting the login to a specific IP address: “something you are” and “something you have”, are now combined to give 2FA. For users who connect in, setting the authentication method to be “password and private key authentication” could also be used to allow 2FA. This is set in the “SFTP Auth” or “FTPS Auth” buttons on the users “connections” tab. Setting the SSL/SFTP key authentication options are the same as for “private key only authentication” users.

Advanced Authentication Module

If you do have an existing 2FA system, EFT can integrate with it by using the Advanced Authentication Module (AAM). This functionality is an additional module released late in 2016, allowing Radius calls to be made against the authentication server and prompt for one time passwords during a login process. (Existing users who have implemented 2FA should contact us before upgrading to version 7.3.3. or above.)

The AAM module on EFT Enterprise allows authentication requests to be passed to RSA SecureID solutions, a Radius server, Common Access card controls or using a SAML/Web Single sign on systems.

Radius Authentication

In Radius authentication, the user or device sends a request to EFT Enterprise to gain access to a particular network resource. EFT Enterprise then sends a RADIUS Access Request message to the RADIUS server requesting authorisation to grant access via the RADIUS protocol.RADIUS servers vary, but most can look up client information in text files, LDAP servers, or databases. The RADIUS server can respond with an Access Reject, Access Challenge, or Access Accept. If the RADIUS server responds with an Access Challenge, additional information is requested from the user or device, such as a secondary password. Access Accept and Access Reject allow or reject the user access respectively.

Common Access Card

When Common Access Card is enabled on an EFT Enterprise LDAP Site, clients are required to provide a certificate when connecting. Once the user’s certificate is validated, EFT uses the Principal Name (UPN) or RFC822 Name taken from the Subject Alternative Name (SAN) field of the Signature Certificate to search for the user in LDAP. Access is then denied or allowed based on the information found. The certificate provisioned via the web browser must have an Electronic Data Interchange Personal Identifier (EDI/PI). If the EDI/PI is not found or otherwise cannot be validated, the connection is denied. If the EDI/PI is found, EFT maps the corresponding fields in LDAP using the appropriate LDAP query string. If the user is found in LDAP, a certificate is assigned to that user, and if the certificate exactly matches the one provided by the client, the user is allowed access

HTTP and HTTPS protocols in EFT

The HTTP and HTTPS protocols in EFT provide the SAML 2.0 Web SSO profile with HTTP POST binding and corresponding the user interface controls to enable and configure SAML for achieving Single Sign On (SSO) for Web-based authentication. This allows EFT to make a web service call to validate a user’s access if they are already logged into another system. If the web service comes back with a authenticated login, the system will allow access to the user without prompting for additional credentials. This means that EFT can be transparently integrated into a validated website, such as a CRM system, without the need to separately login to EFT to upload a file. As these authentication options are all governed by the EFT server, there is no additional work required to allow them to be used with users connecting through a DMZ gateway server.