secureauth access gateway best practices guide · the difference between the secureauth access...

SecureAuth Access Gateway VAMBest Practices Guide

Copyright Information

2017. SecureAuth© is a copyright of SecureAuth Corporation. SecureAuth’s IdP software, appliances, and other products and solutions, are copyrighted products of SecureAuth Corporation.

February, 2017

For information on supporting this product, contact your SecureAuth sales representative:

Email: [email protected]

Phone: +1.949.777.6959 or +1-866- 859-1526

Website: https://www.secureauth.com/Support.aspx

mailto:[email protected]

https://www.secureauth.com/Contact-Us.aspx

Contents

Introduction 1Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Traditional Role of a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Identity Federation and Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Secure Network Architecture Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Eliminating DMZ and Cybersecurity Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Network Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Preventing Data Duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7No Front-End Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Forward Proxy vs. Reverse Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Uses of Reverse Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Solution Architecture 11Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Requirements 13Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Deployment Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Deployment 14External Access Gateway Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Internal Access Gateway Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

How It Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Access Gateway VAM Best Practices Guide

The Difference between the SecureAuth Access Gateway and a Reverse Proxy Server . . . . . . . . . . . . . 16

Security Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Layer 3 and 4 Attacks Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Thorough Traffic Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20Universal Authentication and Legacy Application Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Installation and Configuration 21Configuring the Virtual Machine on the Internal Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Reserving Firewall Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Defining Internal and External Gateway Pairs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Licensing the Access Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Setting the Required SecureAuth IdP Post-Authentication Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Defining the Reverse Access Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Defining the Proxy Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Changing Login Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Use Cases 34Identity Assertion Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Legacy Application Support, Universal Authentication – Kerberos/IWA. . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Legacy Application Support, Universal Authentication – NTLM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

2-Factor Authentication for Non-HTTP Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

IntroductionThe SecureAuth Access Gateway Value-Added Module (VAM) is a breakthrough secure data access solution. Based on SecureAuth’s secure reverse-access technology, Access Gateway overcomes the challenges of today’s DMZ networks and network segmentation, prevents criminal application access, and protects classified networks within the enterprise infrastructure. SecureAuth’s secure front-end solution eliminates the need to store sensitive data in the DMZ, thereby reducing exposure to data breaches.

Acting as a single point of entry, SecureAuth Access Gateway provides an advanced workflow-enabled layer 7 proxy with reverse access technology to facilitate and control authentication and access control in a seamless and secure way. SecureAuth Access Gateway adds a revolutionary level of protection to applications by not only providing an identity through an advanced authentication process, but also by securing unauthenticated traffic from ever reaching back-end application servers.

SecureAuth Access Gateway introduces universal authentication and legacy application support without using agents or clients. This enables the streamlining of authentication across the entire organization for any type of application, even if it doesn’t support identity federation. This includes NTLM, Kerberos and Header authentication.

Focused on providing security solutions for the enterprise market, SecureAuth enables organizations to benefit from enhanced productivity, efficiency, heightened security, and improved regulatory compliance.

SecureAuth’s trademarked approach to securing the network from the outside removes the need to open any ports within the internal firewall, providing unmatched protection for enterprise data networks from the Internet and other public networks.

BackgroundThe SecureAuth Access Gateway changes both the traditional role of the firewall and the DMZ in network security and the way in which Identity Federation is managed to enhance that security.

Introduction 1

Access Gateway VAM Best Practices

To begin, there was the firewall. Which seemed a great advance in network security.

FIGURE 1. The Original Firewall Design

The problem, however, with this was that almost anyone really interested in breaking into a company website or network, could manage it with relative ease. The main problem was that there were too many open ports allowing access to application on the LAN. All it took was a reasonably competent hacker with a port sniffer, to detect one of these vulnerable ports and gain access to the company’s internal network.

In an effort to combat attacks, companies started to use DMZs – which incorporated not one but two firewalls (see “Traditional Role of a DMZ” on page 3).

• External employees and guests were granted access to the LAN• Hackers utilized the open ports to attack the Firewall • Hackers attacked applications & compromised the entire LAN

• All the applications were hosted in the LAN• The Firewall had open ports to allow access to the applications in the LAN

Company Web site

Internal Network

External Users User

Introduction 2


Traditional Role of a DMZ

Ninety percent of organizations around the world today deploy a DMZ in order to provide customers, partners, and suppliers with controlled access to corporate data as shown in Figure 2.

FIGURE 2. Traditional DMZ Role

As more and more sensitive data from the internal network is duplicated in the DMZ, this perimeter network designed to be a buffer zone has become a prime target for hackers, providing IT departments with the following challenges:

+ Risk of Sensitive Data Breach – the DMZ is now a hub of external facing services containing large amounts of sensitive data and personally identifiable information resulting in greater risk of data breaches.

+ Preventing Hacking into the Internal Network from the DMZ – most front-end servers located in the DMZ communicate with servers within the LAN through an incoming port in the firewall, which hackers can utilize to launch attacks into the internal network. In addition, such servers are accessible from the Internet and can be compromised by hackers, providing a second means of attacking the internal network.

+ Increased Capital Costs – the DMZ network configuration also imposes a costly burden on the enterprise’s capital expenses requiring additional hardware and software licenses as a result of duplicating sensitive data in the DMZ.

+ Higher Operational Costs – This additional hosting and synchronization of duplicated data between the LAN and DMZ requires a complex layer of data and network operations which can be complicated.

External User• The DMZ was created to limit external access to the LAN• External facing applications were moved to the DMZ• External users can only access the DMZ

Front End Server

Internal NetworkDMZ

Introduction 3


To adapt to these challenges, IT departments developed more sophisticated DMZ constructions, like Figure 3:

FIGURE 3. DMZ Design: the Next Step

However, that did not stop the development of evermore sophisticated intrusion methods since the speed with which both Identity Federation and Identity Management were being adopted made security a moving target.

Identity Federation and Identity Management

The fast-growing IT environment in organizations created the need to manage identities and access control centrally in a secure fashion without having to rely on an individual application’s user repository or authentication schemes. Separating user authentication from applications and centrally managing them using SecureAuth IdP has provided organizations with the following key advantages:

+ Authentication Security – Increase security without impacting users who are employing adaptive authentication and adaptive authentication work flows, multi-factor authentication and continuous authentication.

+ Single Sign-On – Enable users to use a single password for logging into applications by streamlining secure access into all applications and resources with one set of credentials, whether they are cloud, mobile, web or VPN resources. The result is an improved user experience without tedious login procedures and high-friction authentication work flows, keeping end users happy.

+ User Self-Service – Reduce the help desk burden by balancing security and a clean, frictionless user experience. Rather than waiting for the help desk to change lost or

• Today, more and more applications are migrated into the DMZ• The DMZ contains all the external facing applications

• Large volume of sensitive data now resides in the DMZ• Many ports are now open in the Firewall• Hardware and application licenses are duplicated• Network design complexity increases• Operational costs sky rocket

Internal Network

External User

DMZ

Introduction 4


forgotten passwords, SecureAuth IdP enables users to securely reset their own passwords and unlock their account via a two-factor authentication process that takes only seconds.

+ APIs – SecureAuth IdP’s Adaptive and Authentication APIs enable your organization to embed IdP’s unique access control functionality into custom built applications, thereby delivering strong and adaptive authentication and enabling flexible work flows that meet each resource’s unique needs

Secure Network Architecture TechnologySecureAuth’s Access Gateway Secure Front-End solution is designed to overcome the challenges of today's DMZ networks and add unmatched protection to any back-end application. With Access Gateway, organizations start their journey to complete elimination of the DMZ, close incoming ports in the firewall, and eliminate sensitive data and application servers from the DMZ while gaining immediate cost savings. Servers and applications potentially required to reside in a DMZ environment (such as IdPs, Active Directory domain controllers, and databases) can now be secured on the internal network without exposing open ports from the DMZ, while simultaneously remaining transparent to both end users and back-end applications.

The Access Gateway is a dual-node patented approach for securing the network from the outside, removing the need to open any ports within the internal firewall. Access Gateway Secure Front-End solution is a two-tier deployment:

+ External Access Gateway node – installed in the DMZ segment

+ Internal Access Gateway node – installed in the LAN segment

The role of the external Access Gateway node is to act as a front-end to all services published within the DMZ, including SecureAuth IdP and back-end applications. It operates without the need to open any ports within the internal firewall and ensures that only legitimate session data can pass through into the LAN.

The role of the internal Access Gateway node is to pull the session data into the LAN from the external Access Gateway node, scan it using various application level security techniques, and determine whether or not the user is authenticated. If the user is authenticated, the traffic will

NOTE: All SecureAuth gateway nodes are Linux virtual machines.

Introduction 5

https://app1.company.com


be relayed to the destination application. If the user is not authenticated, the traffic will be relayed to SecureAuth IdP portal to authenticate and determine identity.

FIGURE 4. Access Gateway Network Architecture

Eliminating DMZ and Cybersecurity Threats

By deploying Access Gateway in the network, IT and application teams can now:

+ Simplify network and DMZ architecture.

+ Gain immediate costs savings by eliminating duplicated application licenses and hardware costs (including legacy network access solutions and reverse proxies).

+ Achieve increased operational efficiency by reducing constant data synchronization.

+ Eliminate sensitive data from DMZ, preventing compromising of sensitive data.

+ Improve data security by closing firewall ports that are constantly exploited by external hackers.

+ Shorten the time frame for regulation compliance.

+ Remove the organization’s reliance on a reverse-proxy to ensure security.

+ Ensure end users maintain their SLA’s and user’s experience.

+ Prevent users from sending traffic to an application before they go through the SecureAuth IdP advanced authentication process.

Network Protection

All the interaction with back-end services is done on the internal network without opening any ports from an external network. All the network connectivity is initiated from the internal network to the outside world (a patented reverse-access technology).

Internet

Apps

Servers on LAN

DB Web Mail

DMZ

IdP ServerAccess Gateway Internal Node

Access Gateway External Node

Introduction 6


Preventing Data Duplication

All information that is exchanged between end users, the SecureAuth IdP, and back-end applications is not saved in any server in the DMZ, even temporarily. Only approved, validated, and authenticated traffic reaches the application servers on the internal network. With this approach, no harmful data can be sent to an application in an attempt to compromise its identity validation mechanism and hack in without authenticating.

FIGURE 5. Network Protection

No Front-End Servers

The use of the SecureAuth Access Gateway enables you to avoid the use of front-end applications exposed to the Internet. With SecureAuth’s solutions, no application or data intelligence is stored in the DMZ. SecureAuth Access Gateway only requires a single “no-brain” server in the DMZ that does not contain any encryption keys, certificates or user credentials. Taking over that server does not enable any data theft and does not allow access to the internal network.

Forward Proxy vs. Reverse ProxyProxy servers were invented to add structure and encapsulation to distributed systems. Today, most proxies are web proxies, facilitating access to content on the Internet and providing anonymity. There are two main sorts: forward and reverse proxy.

User

Encrypted DBAccess Gateway Server

DMZ Internal Network

Reduced Cost : No application licenses and hardware duplication

Reduced Complexity : No data is duplicated or synced

Security Issue #2: Fixed. No data is stored outside the organization LAN external user authorization

Security Issue #1: Fixed. No incoming holes in the firewall

Access GatewayExternal Node

Access Gateway

Internal Node

Introduction 7


A forward proxy server – normally referred to as a proxy server – is a server that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service – such as a file, connection, web page, or some other resource available from a different server – and the proxy server evaluates the request as a way to simplify and control its complexity.

FIGURE 6. Forward Proxy Example

In this example, Spacely Sprockets does not know to whom the information is going and is trusting to the proxy to vouch for the authenticity of Acme Technology. As you can imagine, there are inherent problems with assuming too much about the reliability of a request using this model.

A reverse proxy server retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as if they originated from the proxy server itself. While a forward proxy acts as an intermediary for its associated clients to contact any server, a reverse proxy acts as an intermediary for its associated servers enabling it to be contacted by any client.

Proxy Spacely SprocketsAcme Technology

Request a price list for Spacely Sprockets

I need a price list for sprockets

Here s the price list.Here s the price list you requested

Introduction 8


A reverse proxy takes requests from the Internet and forwards them to servers in an internal network. Those making requests to the proxy may not be aware of the internal network.

FIGURE 7. Reverse Proxy Flow

Quite often, web servers utilize reverse-proxy functionality, to act as a shield for application frameworks with weaker HTTP capabilities.

The way in which SecureAuth has adopted the reverse proxy, is shown in Figure 8.

FIGURE 8. SecureAuth Access Gateway Reverse Proxy

For more on reverse proxy as used in the SecureAuth Access Gateway, see “The Difference between the SecureAuth Access Gateway and a Reverse Proxy Server” on page 16.

Internet

Proxy Web Server

Internal Network

Access Gateway External

• Access Gateway is composed of 2 nodes: External & Internal• Incoming requests to applications arrive to the External Access Gateway node• The Internal Access Gateway immediately pulls them into the LAN on an outbound

connection• The request is sent to the application for response, and the reply is sent back• The firewall opens a port only from the LAN to the DMZ


Access Gateway Internal

Introduction 9


Uses of Reverse ProxyThe various uses for reverse proxy are highlighted below:

+ Reverse proxies can hide the existence and characteristics of an origin server or servers.

+ Application firewall features can protect against common web-based attacks. Without a reverse proxy, removing malware for example, can become difficult.

+ In the case of secure websites, a web server may not perform SSL encryption itself, but instead offloads the task to a reverse proxy that may be equipped with SSL acceleration hardware.

+ A reverse proxy can distribute the load from incoming requests to several servers, with each server serving its own application area. In the case of reverse proxy in the neighborhood of web servers, the reverse proxy may have to rewrite the URL in each incoming request in order to match the relevant internal location of the requested resource.

+ A reverse proxy can reduce the load on its origin servers by caching content, either static or dynamic - also known as web acceleration. Proxy caches of this sort can often satisfy a considerable number of website requests, greatly reducing the load on the origin server(s).

+ A reverse proxy can optimize content by compressing it in order to speed up loading times.

+ In a technique known as “spoon-feeding” a dynamically generated page can be produced all at once and served to the reverse-proxy, which can then return it to the client at a more digestible rate. The program that generates the page need not remain open, thereby releasing server resources during the possibly extended time the client requires to complete the transfer.

+ Reverse proxies can operate wherever multiple web-servers must be accessible via a single public IP address. The web servers listen on different ports in the same machine, with the same local IP address or, possibly, on different machines and different local IP addresses altogether. The reverse proxy analyzes each incoming request and delivers it to the right server within the local area network.

+ Reverse proxies can perform A/B testing and multivariate testing without placing JavaScript tags or code into pages.

+ Commercial or enterprise level out-of-box solutions exist and can have an agent installed on user systems to ensure a constant connection to a cloud proxy / reverse proxy server also a SaaS solution.

+ A reverse proxy can add basic HTTP access authentication to a web server that does not have any authentication.

Introduction 10


Solution ArchitectureThe essential architecture of the Access Gateway solution is described in the following sections.

TopologyAn illustration of the SecureAuth Access Gateway topology is shown in Figure 9.

FIGURE 9. Access Gateway Topology Example

The following steps describe the process flow (refer to the circled red numbers above):

1. An external user types a unique identity federation-enabled application address in a web browser (for example, https://app1.company.com). All the unique application addresses resolve to the external Access Gateway.

2. The request is stopped at the external Access Gateway node and is then pulled on an outbound connection to the internal Access Gateway node.

3. The internal Access Gateway node performs SSL offloading using a pre-installed certificate matching the published FQDNs and checks if the request contains a valid identity assertion. If a valid identity assertion is found, skip to step 6.

4. If no valid identity assertion is found, the internal Access Gateway node reverse-proxies the user to the SecureAuth IdP web portal to authenticate.

5. Once the user is authenticated by SecureAuth IdP, it sends back an identity assertion to the internal Access Gateway node.

6. The internal Access Gateway node reverse-proxies the user to the destination back-end application with the identity assertion that it received from the SecureAuth IdP server.

Internet

Web App 1

Internal FWExternal FW Web App 2

Web App 3

DMZ

User

Internet LAN

SecureAuth IdP

1

2

3

45

6





Access Gateway Internal Node

Solution Architecture 11


Key PointsThe key points of this flow are:

+ Increased security. No application servers or data reside in the DMZ.

+ No open ports are required. Ensure that organizations do not deploy any DMZ components which can be hacked and utilized to access the network.

+ Terminates TCP sessions at the DMZ and performs offloading to reverse the direction of the traffic.

+ Increases security by preventing users from being able to interact directly with an application before they authenticate and acquire an identity assertion.

+ Target applications are managed on a single address, seamless interaction with SecureAuth IdP, no hopping and redirects between an application address and an IdP address.

Solution Architecture 12


Requirements

Hardware RequirementsSecureAuth products, including the Access Gateways, are delivered as virtual appliances. A virtual infrastructure (such as VMware) is required to run SecureAuth products.

The following table describes the minimum resources needed to operate the node virtual machine:

Deployment PrerequisitesThe requirements for deployment of this product are:

+ A VMware virtualization environment.

+ Administration privileges to the servers, including vSphere console control and/or SSH.

+ The minimum hardware resource requirement (as specified in this document).

+ Allocation of IP addresses to all the virtual machines.

+ A public FQDN DNS record (such as app.company.com) that points to the external Access Gateway node per published application.

+ SSL certificate for the FQDN address (a wild-card certificate for the domain is required when using multiple applications on different sub-domains, for example, *.company.com) in a standard format (normally PFX). A self-signed certificate may be used but might generate an SSL warning on web browsers.

+ Open outbound ports (as specified in the previous table).

TABLE 1. Minimum Virtual Resource Requirements

SecureAuth Product

# of Virtual Machines

Min. Resources Required OS TCP Ports

Access Gateway Node(Internal and External)

2 CPU: 2x2 cores

RAM: 4 GB

Storage: 15 GB

Linux 808 and 444 from the Internal Access Gateway node to the external node.

External node is only open and listening on TLS/SSL port 443.

Internal node to the back-end application on port 443.

Requirements 13


DeploymentThe deployment process involves the steps and procedures shown in Table 2.

SecureAuth's Access Gateway Secure Front-End solution is a two-tier deployment:

+ External Access Gateway Node – installed in the DMZ segment

+ Internal Access Gateway Node – installed on a LAN segment

External Access Gateway NodeThe role of the external Access Gateway node is to act as a front-end to all services published within the DMZ, operating without the need to open any ports within the internal firewall, it ensures only legitimate session data can pass through into the LAN. The external Access Gateway node can be deployed in two main locations within the DMZ either before the web/application front-ends, essentially replacing them completely.

Or after the web/application front-ends providing an additional layer of defense within the DMZ and preventing any attacks from being generated from within the front-end servers. Regardless of the location in which the external Access Gateway node is located (before or after the web/application front-ends), its main capability of ensuring secure connectivity into the internal network, allows to move any user directory (such as Active Directory) and database services from the DMZ into the internal LAN.

TABLE 2. Deployment Process

Step 1: Server Deployment

Allocating Virtual Resources

Deploying OVA Images Product and License Activation

Step 2:Installation and configuration

Basic Configuration

IP Addresses

Connectivity to IdP Server

Connectivity to Published Applications

Basic Functionality Tests

Step 3:Administrator Training and End-user Deployment

End-to-End Tests Administration

Training

Deployment 14


Internal Access Gateway NodeThe role of the internal Access Gateway node is to pull the session data into the LAN from the external Access Gateway node, scan it using various security techniques and pass it to the destination (either the application for previously-authenticated sessions, or to SecureAuth IdP for non-authenticated traffic).

FIGURE 10. Deployment Example

How It WorksThe operation process is as follows:

1. A full session is initiated from the internal Access Gateway node to the external Access Gateway node on TCP port 808.

2. Every few milliseconds, the internal Access Gateway node polls for new sessions that arrived to the external Access Gateway node from external clients.

3. When an incoming request from the Internet, it reaches the external Access Gateway node over the designated service port (such as TCP port 443 for HTTPS traffic), the external Access Gateway node does the following:

a. Strips the key attributes from the request (port number, protocol, IP, URL, and so on)

b. Verifies the request (for example, port and white/black lists)

User

DB ServerApplication Server

IP = 109.65.4.196

IP = 109.168.1.52 IP = 10.1.1.12

IP = 10.1.1.10 IP = 10.1.1.11

User ‐> Front‐End Segment

Front‐End ‐> Access Gateway External Segment

Access Gateway Internal ‐> Access Gateway External

Segment

Access Gateway Internal ‐> App Server Segment

App Server ‐> DB Server Segment

S.IP = FW DMZ InfD.IP = 192.168.1.51

S.IP = 192.168.1.51D.IP = 192.168.1.52

S.IP = 10.1.1.12D.IP = 192.168.1.52

S.IP = 10.1.1.12D.IP = 10.1.1.10

S.IP = 10.1.1.10D.IP = 10.1.1.11

Access Gateway Internal NodeAccess Gateway External Node

Deployment 15


c. Holds the raw request data in a queue.

The internal Access Gateway Node does the following:

a. Creates a session to the destination server over the designated port.

b. Creates a callback session to the external Access Gateway node over the callback port.

4. The internal Access Gateway node then pulls the TCP session data from the external Access Gateway node, verifies the data, and forwards it to designated server.

5. The reply from the designated server returns to the internal Access Gateway node and pushed back to the external Access Gateway node over the callback port.

6. The external Access Gateway node then forwards the reply to the source client.

The designated server is determined based on the existence of an authentication session with identity assertion. It can be either the actual back-end application or the SecureAuth IdP authentication portal.

For detailed instruction on how to install and configure the Access Gateway, see “Installation and Configuration” on page 21.

The Difference between the SecureAuth Access Gateway and a Reverse Proxy ServerAs explained in “Forward Proxy vs. Reverse Proxy” on page 7, a reverse proxy is a “backwards” proxy-cache server; it's a proxy server that, rather than allowing internal users to access the Internet, lets Internet users indirectly access certain internal servers.

FIGURE 11. Access Gateway versus Reverse Proxy

The reverse-proxy server is used as an intermediary by Internet users who want to access an internal website, by sending its requests indirectly. With a reverse proxy, the web server is protected from direct outside attacks, which increases the internal network's strength.

However, for a reverse proxy to operate, the IT administrator must allow certain protocols to pass through the internal firewall and connect to specific hosts in the internal network (such as TCP Port 80/443 for web or Microsoft Share Point applications). With this configuration, the reverse proxy can access the internal network directly.

Too often, administrators seeking to troubleshoot a problem create a rule allowing full access between a DMZ system and a back-end server on the internal network (or the entire internal network).

Deployment 16


As can be seen above, the use of a reverse proxy creates various security and application challenges:

1. Once incoming ports are open in the internal firewall, the DMZ is effectively merged with the internal network.

2. If an external attacker compromises the reverse proxy server, the attacker may also be able to get access into the company’s internal servers, applications, and internal network.

3. A large number of translations must be done between the reverse proxy and the firewall adding latency to user application requests.

However, Access Gateway does not open any incoming ports in the internal firewall, ensuring that the DMZ and LAN are totally separated environments. In addition, since the external Access Gateway node does not run any application but rather acts as a listener, it decreases the possible attacking vectors.

To better understand the solution, let’s examine an example. This presents a standard 3-tier SharePoint deployment, where the web front-end is deployed in the DMZ and the application and DB servers are deployed in the LAN.

FIGURE 12. Traditional Use of Reverse Proxy

This deployment is mostly used to serve external users, and while the benefit is that external users are restricted to the DMZ, it does create four challenges:

+ there are constant incoming ports open in the firewall

+ sensitive data is stored in the DMZ

Security Issue #1: Constant incoming hole

in the Firewall

Security Issue #2: Data is stored outside the organization LAN

Complexity: Data is duplicated and

constantly synched

Cost: Duplicated Application licenses and

Hardware

User

SharePointApplication Server

SharePoint Web Front-endSharePoint DB Servers


Deployment 17


+ the complexity of synchronizing the data between the different application tiers which reside in different parts of the network

+ the high costs due to duplication of servers and licenses

Now that we understand the issues of deploying a SharePoint solution where parts of it are in the DMZ and other parts are in the LAN, let’s see how deploying SecureAuth Access Gateway can address the issues as shown in Figure 13.

FIGURE 13. Deploying SecureAuth Access Gateway in the Solution

1. Start by deploying the internal Access Gateway before the SharePoint application server.

2. Next we deploy the external Access Gateway in the DMZ, replacing the SharePoint front-end.

3. The internal Access Gateway constantly monitors the external Access Gateway for new requests.

4. Once a user generates a request to the SharePoint application it is intercepted by the external Access Gateway which represents the SharePoint application to the external world.

5. The internal Access Gateway then immediately pulls the request into the LAN and sends it to the SharePoint application server.

6. The response is sent back from the application server, via both Access Gateway nodes to the user.

The benefits of deploying Access Gateway in this example are:

+ Open incoming ports are closed.

SharePoint Application Servers

SharePoint Web Front-end SharePoint DB Servers

User


Access Gateway

InternalAccess Gateway

External

2. The request is captured

by the External Access Gateway.

1. User request flow

3. The Internal Access Gateway is constantly checking for new

requests

5. Once there is a request to handle, the

Internal pulls it

4. The request is sent to the Application

server

6. The reply is sent in the same connection. No need for incoming

firewall hole

Reply

Request

Deployment 18


+ Sensitive data residing in the DMZ is restricted to the internal network behind the front-end gateway

+ There is no need to synchronize data between the LAN and DMZ

+ Cost is greatly reduced, since there is no need for hardware in the DMZ

FIGURE 14. Advantages of Using Access Gateway in this Example

Security BenefitsThere are at least four key benefits derived from using SecureAuth Access Gateway technology.

Layer 3 and 4 Attacks Protection

The main benefit of the Access Gateway’s unique technology, that allows passing session data into the internal network without opening any inbound ports on the internal firewall, is that it allows the complete block of any network or Layer 4- based attacks such as port scans, ICMP scans, SYN floods and other TCP based attacks and prevents it from occurring on the firewall or the internal network.

Access Gateway External Access Gateway Internal

SharePoint Application Servers

SharePoint Web Front-end SharePoint DB Servers

User


Security Issue #1: Constant open hole in

the Firewall

Security Issue #2: Data is stored outside the organization LAN

Complexity: Data is duplicated and

constantly synched

Cost: Duplicated Application licenses

Security Issue #1: Fixed. No incoming holes in the Firewall

Security Issue #2: Fixed. No data is stored

outside the organization LAN

Reduced Complexity: Data is not duplicated

and synched

Reduced Cost: No Application licenses

and Hardware duplication

Deployment 19


Access Control

Access Gateway offers a comprehensive access control module which allows application-level access control, limiting access of specific source IPs to specific application services.

Thorough Traffic Inspection

In contrast to packet filtering firewalls, the Access Gateway handles network connections on a proxy level. The Access Gateway ends connections on one side and establishes new connections on the other; that way the transferred information is available on the device in its entirety, enabling complete protocol inspection. This enables organizations to examine and centrally monitor all traffic, as well as alter that traffic to enhance features. For example, behavioral biometrics can be applied to not only the SecureAuth IdP portal but also to any web-based application to create an unmatched user profile (unique typing sequences and mouse movements) and facilitate continuous authentication.

Universal Authentication and Legacy Application Support

Applications use a variety of single sign-on and identity federation technologies. Access Gateway supports any type of federation as well as legacy applications with no federation support without using agents or clients. This is achieved by validating the standard identity assertion from the SecureAuth IdP on Access Gateway instead of relying on the application’s ability to validate it itself. Once it is validated, Access Gateway generates valid authentication data that the application does support (such as Kerberos, NTLM Windows Authentication, and Header Authentication).

Deployment 20


Installation and ConfigurationAfter reading the general information contained in “Deployment” on page 14, it is time to perform the actual installation and configuration. To do this, you must follow these basic steps:

+ Configuring the Virtual Machine on the Internal Node

+ Reserving Firewall Ports

+ Defining Internal and External Gateway Pairs

+ Licensing the Access Gateway

+ Setting the Required SecureAuth IdP Post-Authentication Values

+ Defining the Reverse Access Rules

+ Defining the Proxy Rules

Each of these procedures to detailed in the following subsections.

Configuring the Virtual Machine on the Internal NodeBefore you can pair the internal and external Access Gateway nodes, you must enter the virtual machine for the internal node and set the needed configuration values.

To do this, follow these steps:

1. Open the virtual machine client application (such as VMware vSphere Client) on which each access gateway node is running.

2. Enter the user name and password to enter the shell.

3. Select the console window option.

4. In the user name field, enter saag.

NOTE: The configurations detailed in this section are one-time parameter assignments. Once set, these initial settings as well as many other values can be changed using the Admin UI tool (see the subsections starting with “Defining Internal and External Gateway Pairs” on page 24).

NOTE: saag is the application used by SecureAuth Access Gateway for monitoring and configuring each node instance.

Installation and Configuration 21


The SSH/Console session appears like Figure 15.

FIGURE 15. SSH/Console Session Screen

SSH is enabled by default on the internal node and is disabled on the external node. This allows a secure SSH connection, if required, between the installer and the internal node via a terminal program like PuTTY.

FIGURE 16. PuTTY Example

5. Select the 1) Advanced option.

The Advanced option page appears like Figure 17:

FIGURE 17. Advanced Page Screen

6. From this screen you can perform the following functions:

• Select 1. List to review the internal node’s current network settings.

• Select 2. Edit to modify the internal node’s current network settings.

• Enter the values for the internal node’s IP address, gateway, and netmask.

NOTE: The external node should never be accessible via SSH and cannot be reached.



Make sure to write these values down since they will be used when defining the gateways in both the SecureAuth Access Gateway tool and in SecureAuth IdP.

7. Save the configuration and select 9. Back to main menu.

Other procedures you might want to perform while in this shell are:

+ At the main menu, press 2.) Maintenance to review the current status of the network controlled by the virtual machine. The screen that appears looks like Figure 18:

FIGURE 18. Status Screen Example

+ At the main menu, press 9) Exit to exit the this program and return to the virtual machine shell.

Reserving Firewall PortsThe Access Gateway requires several dedicated ports that enable the Internal gateway to communicate with the External gateway. Since you must reserve these ports for the Access Gateway’s exclusive use, you must enter your firewall software configuration program and perform the procedure.

1. Open your firewall application.

2. Select the section that deals with incoming and outgoing rules.

The location of the port rules differs from application to application. For example, using Windows 10 firewall, the port reservations are found under Advanced Settings then the Incoming Rules and Outgoing Rules links (under the View and create firewall rules section).

3. Create new or edit existing rules for the external-to-internal (Incoming) and internal-to-external (Outgoing) access gateway.

NOTE: These reserved ports exist only for the Internal node to poll the External node. There are no direct open ports to the LAN.



4. Set the ports to dedicated values. The ports generally reserved for this operation are:

5. Save and close the firewall application.

Defining Internal and External Gateway PairsIn order to coordinate activity between the internal gateway and an external gateway, you must first set up gateway pairs. To do this, you should use the SecureAuth Access Gateway Admin UI tool.

1. Open your browser and at the URL field, enter the IP address and port where the SecureAuth Access Gateway Admin UI tool is located.

The form of the IP address should be: https:\\100.10.10.10:3000 where the port for access-ing the internal gateway’s configuration tool (:3000 is the default value) appears as the suf-fix preceded by a colon.

The IP address you enter here is determined by the value specified in the virtual machine configuration settings (see Step 6 on page 22).

The login screen appears like Figure 19.

FIGURE 19. SecureAuth Access Gateway Login Screen

2. Enter the username and password at the dialog box then click the Login button.

For the initial entry to the Access Gateway Admin UI tool, use the default values.

Consult your SecureAuth representative for the default username and password you must use. You should change these values as soon as possible. For more on this, refer to “Chang-ing Login Values” on page 32.

3. If a User Identification Request dialog appears, click OK.

Rules Dedicated Port Number

Internal to external node (outgoing)

NOTE: The external node is only open and listening on TLS/SSL port 443.

8888, 8008

Access Gateway tool communications port 3000

SSH communication with the internal node (optional)

2222



The Access Gateway tool appears like Figure 20:

FIGURE 20. SecureAuth Gateway Tool

4. From the top of the left pane, click the add button, .

The Pairs details fields for both the internal and external gateway definition are now acti-vated in the right pane.

5. Enter the values required to specify the location of the internal and external gateway. These include:

6. Click the Save button.

Name Type a unique name for this new pair

Internal

Address Type the IP address of the internal gateway exactly as you defined it in the virtual machine shell.

Port Type the port number that will be used by the internal gateway appliance for communication with the external gateway

External

Address Type the IP address of the external gateway.

Port Type the port number that will be used by the external gateway appliance for communication with the internal gateway



Licensing the Access GatewayBefore continuing, it is a good idea to apply a license to the pair you have just defined. To do that:

1. From the Access Gateway Admin UI toolbar, click to select the Licenses option.

The License management screen like Figure 21 appears.

FIGURE 21. License Management Screen

2. From the Pairs window, click to highlight the pair you just defined.

3. At the bottom of the screen, click Request license for xxx pair where xxx is the name of the pair you specified above.

A dialog like Figure 22 appears:

FIGURE 22. Requesting License

4. Click the Generate license request button.



The Admin UI generates a random number and places it in the License request dialog like Figure 23.

FIGURE 23. License Request Dialog

5. Copy this number and paste it in an email to [email protected] then click Close.

Tailoring Frontline will return a sequence of numbers and letters to your mailbox within sec-onds.

6. Copy this number from the email message.

7. At the License Management screen, click on Apply license for xxx pair.

Copy number from here and paste it into an email


[email protected]


A dialog box like Figure 24 appears.

FIGURE 24. Applying the License

8. Paste the number you were emailed into the Given license: box then click the Apply license button.

The Admin UI is now licensed.

Setting the Required SecureAuth IdP Post-Authentication ValuesBefore continuing with the Admin UI setup, you should now open your SecureAuth IdP web admin and make changes there that will enable SecureAuth IdP to recognize the designated access gateway pair.

To set the required values in SecureAuth IdP:

1. Enter the SecureAuth IdP Web Admin console.

2. Click to select the realm that is associated with this access gateway pairing.

If no realm exists yet for this gateway, you must create a new realm to handle this pairing.

3. Click the Post Authentication tab and go to the ‘Post Authentication’ section.

4. At the ‘Authenticated User Redirect’ drop-down list, select the option appropriate to the communication between the internal and external gateways.

One of two pathways are available from here, depending on the protocol required for this communication:

Paste number here



If the protocol uses SAML assertion, follow these steps:

a. From the ‘Authenticated User Redirect’ drop-down list, select SAML 2.0 (IdP Initiated) Assertion.

The ‘SAML Assertion/WS Federation’ section appears.

b. In the ‘Redirect to’ field, specify the aspx field that will be used to translate the assertion.

c. In the ‘WSFed Reply To/SAML Target URL’ field, type or paste the external gateway’s URL plus specifications like this example:http://172.16.19.58/?ForceSSL=true&IDProviderName=&RelayRoo-tURL=172.16.19.58&ReturnURL=

d. In the ‘SAML Consumer URL’ field, type or paste the internal gateway’s URL plus specifi-cations like this example:https://172.16.19.26/samlconsumer/AssertionConsumer.aspx?binding=urn%3aoa-sis%3anames%3atc%3aSAML%3a2.0%3abindings%3aHTTP-POST

An example of this screen is shown in Figure 25.

FIGURE 25. SAML Assertion Sample Page

If the protocol uses WS Federated, follow these steps:

a. From the ‘Authenticated User Redirect’ drop-down list, select Use Custom Redirect.

b. In the ‘Redirect to’ field, type or paste the specifications for the WSFed provider, such as in this example:Authorized/WSFedProvider.aspx?wa=wsignin1.0&wtrealm=https%3a%2f%2fvm-oc1-cd0509%2fWSFed_App%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fWSFed_App%252fAc-count%252fLogin&wct=2016-11-02T20%3a37%3a03Z&wreply=https%3a%2f%2fvm-oc1-cd0509%2fWSFed_App%2f


http://172.16.19.58/?ForceSSL=true&IDProviderName=&RelayRootURL=172.16.19.58&ReturnURL=

https://172.16.19.26/samlconsumer/AssertionConsumer.aspx?binding=urn%3aoasis%3anames%3atc%3aSAML%3a2.0%3abindings%3aHTTP-POST


An example of this screen is shown in Figure 26.

FIGURE 26. WSFed Sample Page

5. Save the changes to this section and exit the Web Admin.

Defining the Reverse Access RulesOnce SecureAuth IdP has received the necessary specifications for handling the Access Gateway pairing, it is time to re-enter the Access Gateway Admin UI and define reverse access rules. To do this:



1. From the Access Gateway Admin UI main screen, go to the bottom of the screen and click the Add new rule button from the Reverse Access Rules tab as shown in Figure 27.

FIGURE 27. Access Gateway Admin UI Main Screen

2. The Create new rule dialog box appears like Figure 28:

FIGURE 28. Create New Rule Dialog

3. Enter appropriate values for the fields needed to define this rule.

4. When you are finished, click Add.

The new rule appears in the table at the bottom of the Admin UI screen.

5. Create additional rules as required to indicate the nature of the pairing.

6. When you are finished, click the Save button.

Defining the Proxy RulesTo complete configuration of the pair, you must create proxy rules. These are rules that define such things as the keys and the cypher string used.



To create proxy rules:

1. At the bottom of the Admin UI screen, click the Proxy Rules tab.

A text box appears like this:

FIGURE 29. Proxy Rules Section

2. Type or paste the script required to define how to navigate between the external gateway and the application controlled by the internal gateway. This script must include the following information:

• What the SecureAuth proxy does

• What the SSL listening post does

• What the application does

• What the SA identity does

• What the services do

• What cypher string the communication has agreed upon

An example of this script is shown in Figure 30.

FIGURE 30. Proxy Script Example

Changing Login ValuesTo change the user name and password to access the Access Gateway Admin UI, perform these steps:

1. From the Access Gateway Admin UI toolbar, click Settings.

2. From the Settings pane on the left, click User management.



A table like this Figure 31.

FIGURE 31. Password Change

3. Click to select and activate the password column.

4. Type a new password.

5. Click the Save button.



Use CasesThis section provides several use cases for the Access Gateway. These use cases include:

+ “Identity Assertion Front End” on page 34

+ “Legacy Application Support, Universal Authentication – Kerberos/IWA” on page 35

+ “Legacy Application Support, Universal Authentication – NTLM” on page 37

+ “2-Factor Authentication for Non-HTTP Protocols” on page 39

Identity Assertion Front EndThis use case is designed for securing SAML/WS-Fed applications with a standard SecureAuth IdP setup.

FIGURE 32. Identity Assertion Front End Architecture

Process Flow1. An external user types a unique specific federation-enabled application address in a web

browser (e.g. https://app1.company.com). All the unique application addresses resolve to the external Access Gateway.

2. The request is stopped at the external Access Gateway node and is then pulled on an outbound connection to the internal Access Gateway.

3. Internal Access Gateway performs SSL offloading using a pre-installed certificate matching the published FQDNs and checks if the request contains a valid SAML/WS-Fed assertion. If a SAML/WS-Fed assertion is found, skip to step 6.

Internet

Web App 1


Web App 3

DMZ

User

Internet LAN

SecureAuth IdP

1

2

3

45

6






Use Cases 34




4. If no valid SAML/WS-Fed assertion is found, internal Access Gateway reverse-proxies the user to SecureAuth IdP’s web portal to authenticate.

5. Once SecureAuth IdP authenticates the user, it sends back SAML/WS-Fed assertion to internal Access Gateway.

6. Internal Access Gateway reverse-proxies the user to the destination back-end application with the SAML/WS-Fed assertion that it received from SecureAuth IdP.

Features+ Increased security. SecureAuth IdP’s server can be deployed on the internal network

instead of a DMZ behind a closed firewall. No open ports are required. Ensure that organizations do not deploy any DMZ components which can be hacked and utilized to access the network.

+ Increased security. Terminates TCP sessions at the DMZ and performs offloading to reverse the direction of the traffic.

+ Increased security. Prevent users from being able to interact directly with an application before they authenticate and acquire a SAML/WS-Fed assertion.

+ Target applications are managed on a single address, seamless interaction with SecureAuth IdP, no hopping between an application address and an IdP address.

Legacy Application Support, Universal Authentication – Kerberos/IWAIn this use case, identity assertion from SecureAuth IdP is validated on the Access Gateway instead of relying on the application’s ability to validate it. Once it is validated, Access Gateway generates valid authentication data that the application does support, such as Kerberos or Windows Authentication.

Use Cases 35


FIGURE 33. Legacy Application Support – Kerberos/IWA Architecture

Process Flow1. An external user types a unique specific application address in a web browser (such as

https://app1.company.com). All the unique application addresses resolve to external Access Gateway.

2. The request is stopped at external Access Gateway and is then pulled on an outbound connection to the internal Access Gateway.

3. The internal Access Gateway performs SSL offloading using a pre-installed certificate matching the published FQDNs and checks if the request contains a valid Access Gateway session cookie indicating that the user has already authenticated with SecureAuth IdP. If found, skip to step 8.

4. If no valid Access Gateway session cookie is found, internal Access Gateway reverse-proxies the user to SecureAuth’s web portal to authenticate.

5. Once SecureAuth IdP authenticates the user, it sends back SAML/WS-Fed identity assertion to internal Access Gateway. The data on the assertion contains the Active Directory user name of the user.

6. The internal Access Gateway validates the SAML/WS-Fed identity assertion and extracts the user name from it. It then requests a Kerberos ticket from a domain controller on behalf of the user.

7. The domain controller issues a Kerberos ticket for the user and sends it to the internal Access Gateway.

Internet

Web App 1


Web App 3

DMZ

User

Internet

LAN

SecureAuth IdP

1

2

3

45

6




Active Directory Domain 1

Active Directory Domain 2

7

8



Use Cases 36



8. The internal Access Gateway reverse-proxies the user to the destination application and injects the Kerberos ticket to the request so that the user is seamlessly logged in to the application.

Features+ Enables support for previously unsupported legacy applications that do not support

SAML/WS-Fed, or only partially support it (such as SharePoint and OWA).

+ Enables support for Kerberos legacy applications without deploying dedicated agents on back-end application servers or requiring extensive customizations.

+ Increases security. SecureAuth IdP server can be deployed on the internal network instead of a DMZ behind a closed firewall. No open ports are required. Ensures organizations do not deploy any DMZ components which can be hacked and used to access the network.

+ Increases security. Terminates TCP sessions at the DMZ and performs offloading to reverse the direction of the traffic.

+ Increased security. Prevent users from being able to interact directly with an application before they authenticate.

+ Target applications are managed on a single address, seamless interaction with the IdP, no hopping between an application address and an IdP address.

Legacy Application Support, Universal Authentication – NTLMIn this use case, identity assertion from SecureAuth IdP is validated on the Access Gateway instead of relying on the application’s ability to validate it. Once it is validated, Access Gateway generates valid authentication data that the application does support (such as Kerberos or Windows Authentication).

Use Cases 37


FIGURE 34. Legacy Application Support – NTLM Architecture

Process Flow1. An external user types a unique specific application address in a web browser (e.g. https://

app1.company.com). All the unique application addresses resolve to external Access Gateway.

2. The request is stopped at external Access Gateway and is then pulled on an outbound connection to internal Access Gateway.

3. The internal Access Gateway performs SSL offloading using a pre-installed certificate matching the published FQDNs and checks to ascertain if the request contains a valid Access Gateway session cookie indicating that the user has already authenticated with SecureAuth IdP. If found, skip to step 6.

4. If no valid Access Gateway session cookie is found, internal Access Gateway reverse-proxies the user to SecureAuth IdP’s web portal to authenticate.

5. Once SecureAuth IdP authenticates the user, it sends back SAML/WS-Fed assertion to the internal Access Gateway. The assertion data contains the encrypted Active Directory user name of the user and the password.

6. The internal Access Gateway validates the identity assertion then extracts and decrypts the user name and password from its data. The internal Access Gateway reverse-proxies the user to the destination application and automatically responds to NTLM challenges received by the application so the user is automatically and seamlessly logged into the application.

Internet

Web App 1


Web App 3

DMZ

User

Internet LAN

SecureAuth IdP

1

2

3

45

6






Use Cases 38



Features+ Enables support for previously unsupported legacy applications that don’t support SAML/

WS-Fed, or only partially support it (such as SharePoint and OWA).

+ Enables support for NTLM legacy applications without deploying dedicated agents on back-end application servers.

+ Increases security. SecureAuth IdP server can be deployed on the internal network instead of a DMZ behind a closed firewall. No open ports are required. Ensure that organizations do not deploy any DMZ components which can be hacked and utilized to access the network.

+ Increases security. Terminates TCP sessions at the DMZ and performs offloading to reverse the direction of the traffic.

+ Increases security. Prevent users from being able to interact directly with an application before they authenticate.

+ Target applications are managed on a single address, seamless interaction with the IdP, no hopping between an application address and an IdP address.

2-Factor Authentication for Non-HTTP ProtocolsThe inability to enforce stronger security and authentication to client-based legacy protocols has led many organizations to deploy VPNs and other secure access solutions (such as Citrix) in order to provide access to remotely administering servers and applications (SSH).

The Access Gateway can be used to harness SecureAuth IdP’s advanced features to provide access to such services over HTML5 using a web browser.

Process Flow1. An external user types a unique resource address into a web browser (such as https://

server1.company.com). All the unique resource addresses resolve to the external Access Gateway node.

2. The request is stopped at the external Access Gateway node and is then pulled on an outbound connection to the internal Access Gateway.

3. Depending on the use case, the Access Gateway will facilitate the authentication using SecureAuth IdP and eventually gets the user reverse-proxied to a back-end service (SSH) over an HTML5-based client on the user’s web browser.

Features+ Increases security. Provides seamless 2-Factor authentication for services like SSH.

+ Can replace VPNs and remote-access solutions.

Use Cases 39

secureauth access gateway best practices guide · the difference between the secureauth access...

Documents