Highlight

An Integrated Two-Factor Authentication Solution Using Pulse Connect Secure and Apache HTTP Server

Component communication for the integrated two-factor authentication solution using Pulse Connect Secure and Apache HyperText Transfer Protocol server
Fig. 1. Component communication for the integrated two-factor authentication solution using Pulse Connect Secure and Apache HyperText Transfer Protocol server: a custom application that meets all requirements, including defending against use of Uniform Resource Locator manipulation as means to gain unauthorized access to backend applications.

Achievement

Complex system requirements often can lead to a situation wherein no single product or platform can provide a solution. In these cases, a solution integrating the features of multiple products and platforms is needed. Recently, a program sponsor required discontinued use of a third-party Security Assertion Markup Language (SAML) Identity Provider (IdP) that was being used to implement a two-factor authentication (2FA) solution that fully integrated with Pulse Connect Secure (PCS). The requirements for the new solution were the following:

1.    Provide access to a secure web portal using 2FA that would include a username/password combination as the first factor, and an email passcode challenge as the second factor.
2.    Continue using PCS as the primary platform.
3.    Implement a solution without using the existing third-party SAML IdP.
4.    Implement a solution where the backend applications leverage a HyperText Transfer Protocol (HTTP) request header variable for authentication.
5.    Prevent unauthorized access, which is usually achieved using Uniform Resource Locator (URL) manipulation, to backend applications for users who have not completed the email passcode challenge.

PCS alone could not provide the features necessary to implement a solution to meet all the requirements. The challenge was to leverage the features of additional platforms to design an integrated solution that met all requirements including the one to prevent unauthorized access through URL manipulation.
 

Significance and Impact

The integrated solution prevents an unauthorized user from accessing a backend application via URL manipulation by integrating the features and capabilities of PCS, Apache, and the custom 2FA Gateway Application. Additional controls could be put in place to make this solution even more secure, including the following examples:

  • User session data could be stored using the LDAP or other underlying data storage, such as a database table. This would prevent a user from bypassing the email passcode challenge once a designated amount of time has passed since they last authenticated.
  • The 2FA Gateway Application could be enhanced to set an expiration time for a generated passcode or lock the underlying user account in the LDAP when the user submits an invalid passcode x number of times.
  • HTTP request headers that are used by Apache, but are not needed by Oracle WebLogic, can be deleted as an enhancement to the Authorization Rules. In the mod_wl.conf file, commands can be added to unset headers that fall into this category. 
     

Research Details

PCS–ONLY 2FA CONFIGURATION

A PCS–only 2FA configuration can be implemented to satisfy all the requirements except the one to prevent unauthorized access through URL manipulation. The primary components of such a configuration are as follows: 

  • PCS as the secure web application server that provides a point of presence on the Internet.
  • Apache HTTP Server acting as the internal (backend) web server.
  • Oracle WebLogic Server acting as the internal (backend) application server.

For a PCS–only configuration, Apache simply acts as the HTTP listener for the applications running on the Oracle WebLogic Server. 

PCS Configuration Components

To gain a deeper understanding of the PCS–only 2FA configuration and the integrated solution, an understanding of the relevant components of a PCS configuration is necessary. The relevant components are as follows:

  • Sign-in Policy – Defines the URL used to access the secure web portal.
  • Authentication Realm – Defines the security realm associated with the sign-in policy and includes the following four components: 1) Authentication Server, 2) Additional Authentication Server, 3) User Directory/Attribute Server (Authorization Server), and 4) Role Mapping Rules. 
  • User Roles – Assignment based upon the role mapping rules.
  • Web Access Control List (ACL) – Allows access to backend resources based upon assigned user roles.
  • Custom Headers – Sends defined HTTP request headers to the backend application based upon assigned user roles. PCS enhances security by preventing custom headers from appearing in the end user’s browser.

There are several authentication server types supported by PCS. The relevant server types are as follows:

  • Lightweight Directory Access Protocol (LDAP) Server
  • Active Directory
  • Remote Authentication Dial-In User Service (RADIUS) Server
  • Certificate Server
  • SAML Server
  • Time-based one-time password (TOTP) Server

PCS–Only Detailed Authentication Flow

The following list describes the authentication flow for the PCS–only configuration:

  • User john.doe initiates access to the secure web portal by accessing the URL.
  • User john.doe authenticates using the username and password of account on the LDAP server.
  • Upon successful authentication, the PCS configuration assigns user roles including those needed to access the 2FA Gateway Application and the secure portal main menu.
  • Based upon the assigned user roles, the PCS configuration also creates ACLs that allow the user to access the 2FA Gateway Application and the secure portal main menu and redirects the authenticated portal user to the landing page of the 2FA Gateway Application.
  • User john.doe accesses the landing page of the 2FA Gateway Application, then the application generates the random passcode and emails it to the end user.
  • User john.doe submits a valid passcode and is redirected to the secure portal main menu.

URL Manipulation Vulnerability of PCS–Only Configuration

The authentication flow is vulnerable to URL manipulation. User roles and web ACLs are assigned by PCS at the conclusion of the authentication process. In this example, this is right after a valid username/password is provided but before the email passcode challenge is completed. A PCS configuration does not include the capability to circle back and refresh the user roles after the email passcode challenge is completed. In addition, since the 2FA Gateway Application is a backend application, access cannot be an integrated part of the authentication process.

The following scenario illustrates unauthorized access to the secure portal main menu using URL manipulation:

  • User john.doe accesses URL for secure portal (https://portal.acme.gov).
  • User john.doe authenticates with username/password.
  • User john.doe is assigned user roles for accessing 2FA Gateway Application and portal main menu.
  • User john.doe is redirected to 2FA Gateway Application, which triggers an email to john.doe@acme.gov containing a passcode.
  • Prior to submitting the valid passcode, john.doe manipulates the URL to access the secure portal main menu (https://portal.acme.gov/mainmenu).

INTEGRATED SOLUTION

The integrated solution uses existing features of PCS and Apache, along with the custom 2FA Gateway Application, to establish communication between system components to prevent URL manipulation. With communication mechanisms in place, Apache can be configured to implement authorization rules requiring an end user to complete the email passcode challenge before allowing access to backend applications. The mechanisms used to establish communication among PCS, Apache, the LDAP server, and the 2FA Gateway Application include HTTP request headers and LDAP server attributes. 

Two different views for the authentication flow of the integrated solution are provided in this section. The first view (discussed in Component Communication) emphasizes the constructs used for component communication. The second view (discussed in Authorization Rules) emphasizes the constructs used to implement the Authorization Rules. Prevention of URL manipulation is discussed in URL Manipulation Prevention in Integrated Solution.

Component Communication

The component communication required to implement the integrated solution is shown in Figure°1. The communication flow among the components of the integrated solution includes the following:

  • User john.doe accesses the sign-in page of the secure web portal.
  • User john.doe authenticates using username and password against the john.doe account in the LDAP server user directory.
  • PCS is configured to pass the following HTTP request headers on to the Apache HTTP Server:
    —    enable_apache_authorization (true|false) – If true, communicates to Apache that the authorization check is active.
    —    Authorization (Basic <Base64 encoded username:password of 2fa service account>) – Basic Authentication header that establishes the user context for the LDAP authorization in Apache.
    —    application_username – Used to pass the authenticated portal username to the backend applications utilizing HTTP header variable authentication.
  • PCS redirects john.doe to the 2FA Gateway Application, which is allowed by the Authorization Rules.
  • Access to the 2FA Gateway Application triggers an email to john.doe@acme.gov containing a passcode.
  • User john.doe submits the passcode from the email, which triggers the 2FA Gateway Application to add the 2fa_service account to the john.doe group in the 2FAGroups container.
  • User john.doe is redirected to the secure web portal main menu, which is allowed by the Apache Authorization Rules.

Authorization Rules

This section delineates a view of the authentication flow for the integrated solution with emphasis on the implementation of the Apache Authorization Rules.
The authentication flow and authorization rules include the following actions:

  • User john.doe accesses the sign-in page of the secure web portal.
  • User john.doe authenticates using the username and password of their account on the LDAP server.
  • Upon successful authentication, the PCS configuration assigns user roles including those to access the 2FA Gateway Application and the secure portal main menu.
  • Based upon the assigned user roles, the PCS configuration also does the following:
    —    Creates ACLs that allow the user to access the 2FA Gateway Application and the secure portal main menu.
    —    Sends the custom HTML request headers (listed in Component Communication with every request to the backend resources.
    —    Redirects the user to the landing page of the 2FA Gateway Application. 
  • The request to access the 2FA Gateway Application is passed through Apache, which controls all access to the backend applications on the Oracle WebLogic Server through Authorization Rules. These rules are defined in the WebLogic module configuration file mod_wl.conf. 
    —    As of Apache Version 2.4, enhancements have been implemented in the configuration file logic for Apache, making it possible to execute IF-THEN-ELSE conditional logic. 
    —    Apache includes the ap_expr parser that allows HTTP request headers to be evaluated as part of a configuration. For example, the expression “%{HTTP:request_header_name}” would allow Apache to retrieve the value of the “request_header_name” request header.
    —    The “IF” condition in the configuration file checks to see if Apache authorization is enabled and if the request is for a backend resource other than the 2FA Gateway Application. If both of these are true, it checks the LDAP to see if the 2fa_service account is a member of the group named john.doe in the 2FAGroups container. This check is made using the “Require ldap-group” directive. If 2fa_service is a member, user john.doe is authorized.
  • Access to the 2FA Gateway Application triggers an email to john.doe containing a passcode.
  • User john.doe submits the passcode from the email that triggers the 2FA Gateway Application to add the 2fa_service account to the john.doe group in the 2FAGroups container.
  • User john.doe is redirected to the secure web portal main menu, which is allowed by the Apache Authorization Rules since user john.doe is authorized.

URL Manipulation Prevention in Integrated Solution

When accessing the secure portal main menu, the logic of the Apache configuration results in an enforcement of LDAP authorization. As previously mentioned, this enforcement is executed with the “Require ldap-group” directive from the Apache configuration file. The user context of the Apache LDAP Authorization Module (mod_authnz_ldap) is determined by the “Authorization” Basic Authentication request header. The value of the header variable takes the ”Basic <Base64 encoded username:password of 2fa service account>” form. For this configuration, access is authorized if the 2FA service account (2fa_service) is a member of the group within the “2FAGroups” container with the same name as the authenticating portal user.

If the user attempts to access the secure portal main menu using URL manipulation prior to successfully completing the email passcode challenge, access is forbidden because the required LDAP group membership does not exist. In other words, the authenticated user is not authorized.

Last Updated: January 15, 2021 - 10:11 am