SecureAuth Access Gateway VAM
Best 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
Contents
Introduction
1
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
Traditional Role of a DMZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Identity Federation and Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Secure Network Architecture Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eliminating DMZ and Cybersecurity Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preventing Data Duplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
No Front-End Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..
..
..
..
..
..
..
..
Forward Proxy vs. Reverse Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
.
.
.
.
.6
.6
.7
.7
7
Uses of Reverse Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Solution Architecture
11
Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Key Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Requirements
13
Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Deployment Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
Deployment
14
External 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Thorough Traffic Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Universal Authentication and Legacy Application Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Installation and Configuration
21
Configuring 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
34
Identity Assertion Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Legacy Application Support, Universal Authentication – Kerberos/IWA. . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Legacy Application Support, Universal Authentication – NTLM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2-Factor Authentication for Non-HTTP Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Introduction
The 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.
Background
The 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.
External Users User
•
•
•
•
•
External employees and guests were granted access to the LAN
All the applications were hosted in the LAN
Hackers utilized the open ports to attack the Firewall The Firewall had open ports to allow access to the applications in the LAN
Hackers attacked applications & compromised the entire LAN
Company Web site
Internal Network
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).
Introduction
2
Access Gateway VAM Best Practices Guide
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.
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
DMZ
FIGURE 2.
Internal Network
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.
Introduction
3
Access Gateway VAM Best Practices
To adapt to these challenges, IT departments developed more sophisticated DMZ
constructions, like Figure 3:
External User
•
•
•
•
•
Large volume of sensitive data now resides in the DMZ
Many ports are now open in the Firewall
Today, more and more applications are migrated into the DMZ
Hardware and application licenses are duplicated
The DMZ contains all the external facing applications
Network design complexity increases
Operational costs sky rocket
DMZ
FIGURE 3.
Internal Network
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
Introduction
4
Access Gateway VAM Best Practices Guide
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 Technology
SecureAuth’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
NOTE: All SecureAuth gateway nodes are Linux virtual machines.
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
Introduction
5
Access Gateway VAM Best Practices
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.
DMZ
Internet
Access Gateway External Node
IdP Server
Access Gateway Internal Node
Apps
DB
Web
Mail
Servers on LAN
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).
Introduction
6
Access Gateway VAM Best Practices Guide
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.
Reduced Cost : No application licenses and hardware duplication
Reduced Complexity : No data is duplicated or synced
User
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 Gateway
Internal Node
Access Gateway
External Node
Access Gateway Server
DMZ
FIGURE 5.
Encrypted DB
Internal Network
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 Proxy
Proxy 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.
Introduction
7
Access Gateway VAM Best Practices
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.
Request a price list for Spacely Sprockets
Acme Technology
Spacely Sprockets
Proxy
Here s the price list you requested
FIGURE 6.
I need a price list for sprockets
Here s the price list.
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.
Introduction
8
Access Gateway VAM Best Practices Guide
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.
Internet
Web Server
Proxy
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.
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 External
Access Gateway Internal
DMZ
Internal Network
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.
Introduction
9
Access Gateway VAM Best Practices
Uses of Reverse Proxy
The 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
Access Gateway VAM Best Practices Guide
Solution Architecture
The essential architecture of the Access Gateway solution is described in the following
sections.
Topology
An illustration of the SecureAuth Access Gateway topology is shown in Figure 9.
https://app1.company.com
https://app2.company.com
https://app3.company.com
User
SecureAuth IdP
1
5
4
Web App 1
2
6
3
External FW
Internet
Internal FW
Access Gateway External Node
Internet
DMZ
Access Gateway Internal Node
Web App 2
LAN
Web App 3
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.
Solution Architecture
11
Access Gateway VAM Best Practices
Key Points
The 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
Access Gateway VAM Best Practices Guide
Requirements
Hardware Requirements
SecureAuth 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:
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
Linux
808 and 444 from the Internal Access
Gateway node to the external node.
RAM: 4 GB
Storage: 15 GB
External node is only open and
listening on TLS/SSL port 443.
Internal node to the back-end
application on port 443.
Deployment Prerequisites
The 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).
Requirements
13
Access Gateway VAM Best Practices
Deployment
The deployment process involves the steps and procedures shown in Table 2.
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
Connectivity to IdP
Server
Basic Functionality
Tests
Step 3:
Administrator Training
and End-user
Deployment
End-to-End Tests
IP Addresses
Connectivity to
Published Applications
Administration
Training
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 Node
The 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.
Deployment
14
Access Gateway VAM Best Practices Guide
Internal Access Gateway Node
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 security techniques and pass it to the
destination (either the application for previously-authenticated sessions, or to SecureAuth IdP
for non-authenticated traffic).
IP = 109.65.4.196
User
IP = 109.168.1.52
Access Gateway External Node
IP = 10.1.1.12
Access Gateway Internal Node
IP = 10.1.1.10
Application Server
User ‐> Front‐End Segment
S.IP = FW DMZ Inf
D.IP = 192.168.1.51 FIGURE 10.
Front‐End ‐> Access Gateway External Segment
S.IP = 192.168.1.51
D.IP = 192.168.1.52
Access Gateway Internal ‐> Access Gateway External Segment
S.IP = 10.1.1.12
D.IP = 192.168.1.52
Access Gateway Internal ‐> App Server Segment
S.IP = 10.1.1.12
D.IP = 10.1.1.10
IP = 10.1.1.11
DB Server
App Server ‐> DB Server Segment
S.IP = 10.1.1.10
D.IP = 10.1.1.11
Deployment Example
How It Works
The 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)
Deployment
15
Access Gateway VAM Best Practices
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 Server
As 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
Access Gateway VAM Best Practices Guide
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.
Cost: Duplicated Application licenses and Hardware
Complexity: Data is duplicated and constantly synched User
Security Issue #2: Data is stored outside the organization LAN
Security Issue #1: Constant incoming hole in the Firewall
SharePoint Web Front-end
DMZ
FIGURE 12.
SharePoint
Application Server
SharePoint
DB Servers
Internal Network
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
Deployment
17
Access Gateway VAM Best Practices
+ 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.
5. Once there is a request to handle, the Internal pulls it
Request
4. The request is sent to the Application server
1. User request flow
2. The request is captured by the External Access Gateway.
User
3. The Internal Access Gateway is constantly checking for new requests
Access Gateway
External
Access Gateway
Internal
6. The reply is sent in the same connection. No need for incoming firewall hole
SharePoint Web Front-end
DMZ
FIGURE 13.
Reply
SharePoint Application
Servers
Internal Network
SharePoint
DB Servers
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 frontend.
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.
Deployment
18
Access Gateway VAM Best Practices Guide
+ 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
Reduced Cost: No Application licenses Cost: Duplicated and Hardware Application licenses
duplication
Reduced Complexity: Complexity: Data is Data is not duplicated duplicated and and synched constantly synched User
Security Issue #2: Security Issue #2: Data Fixed. No data is stored is stored outside the outside the organization LAN
organization LAN
Access Gateway External
SharePoint Web Front-end
DMZ
FIGURE 14.
Security Issue #1: Constant open hole in Fixed. No incoming the Firewall
holes in the Firewall
Access Gateway Internal
SharePoint Application
Servers
Internal Network
SharePoint
DB Servers
Advantages of Using Access Gateway in this Example
Security Benefits
There 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.
Deployment
19
Access Gateway VAM Best Practices
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
Access Gateway VAM Best Practices Guide
Installation and Configuration
After 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
Node
Before 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.
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).
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: saag is the application used by SecureAuth Access Gateway for monitoring and
configuring each node instance.
Installation and Configuration
21
Access Gateway VAM Best Practices
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.
Installation and Configuration
22
Access Gateway VAM Best Practices Guide
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 Ports
The 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.
NOTE: These reserved ports exist only for the Internal node to poll the External node.
There are no direct open ports to the LAN.
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-toexternal (Outgoing) access gateway.
Installation and Configuration
23
Access Gateway VAM Best Practices
4. Set the ports to dedicated values. The ports generally reserved for this operation are:
Rules
Dedicated Port Number
Internal to external node (outgoing)
8888, 8008
NOTE: The external node is only open and
listening on TLS/SSL port 443.
Access Gateway tool communications port
3000
SSH communication with the internal node
(optional)
2222
5. Save and close the firewall application.
Defining Internal and External Gateway Pairs
In 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 accessing the internal gateway’s configuration tool (:3000 is the default value) appears as the suffix 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 “Changing Login Values” on page 32.
3. If a User Identification Request dialog appears, click OK.
Installation and Configuration
24
Access Gateway VAM Best Practices Guide
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 activated in the right pane.
5. Enter the values required to specify the location of the internal and external gateway. These
include:
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
6. Click the Save button.
Installation and Configuration
25
Access Gateway VAM Best Practices
Licensing the Access Gateway
Before 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.
Installation and Configuration
26
Access Gateway VAM Best Practices Guide
The Admin UI generates a random number and places it in the License request dialog like
Figure 23.
Copy number
from here and
paste it into an
email
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 seconds.
6. Copy this number from the email message.
7. At the License Management screen, click on Apply license for xxx pair.
Installation and Configuration
27
Access Gateway VAM Best Practices
A dialog box like Figure 24 appears.
Paste number
here
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 PostAuthentication Values
Before 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:
Installation and Configuration
28
Access Gateway VAM Best Practices Guide
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=&RelayRootURL=172.16.19.58&ReturnURL=
d. In the ‘SAML Consumer URL’ field, type or paste the internal gateway’s URL plus specifications like this example:
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 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-oc1cd0509%2fWSFed_App%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fWSFed_App%252fAccount%252fLogin&wct=2016-11-02T20%3a37%3a03Z&wreply=https%3a%2f%2fvm-oc1cd0509%2fWSFed_App%2f
Installation and Configuration
29
Access Gateway VAM Best Practices
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 Rules
Once 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:
Installation and Configuration
30
Access Gateway VAM Best Practices Guide
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 Rules
To 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.
Installation and Configuration
31
Access Gateway VAM Best Practices
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 Values
To 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.
Installation and Configuration
32
Access Gateway VAM Best Practices Guide
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.
Installation and Configuration
33
Access Gateway VAM Best Practices
Use Cases
This 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 End
This use case is designed for securing SAML/WS-Fed applications with a standard SecureAuth
IdP setup.
https://app1.company.com
https://app2.company.com
https://app3.company.com
User
SecureAuth IdP
1
5
4
Web App 1
2
6
3
External FW
Internet
Internal FW
Access Gateway External Node
Internet
DMZ
Access Gateway Internal Node
Web App 2
LAN
Web App 3
FIGURE 32.
Identity Assertion Front End Architecture
Process Flow
1. 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.
Use Cases
34
Access Gateway VAM Best Practices Guide
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/IWA
In 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
Access Gateway VAM Best Practices
https://app1.company.com
https://app2.company.com
https://app3.company.com
User
SecureAuth IdP
5
1
4
Web App 1
2
3
External FW
Internet
Access Gateway External Node
Internal FW
8
Access Gateway Internal Node
6
Internet
7
DMZ
LAN
Active Directory Domain 1
FIGURE 33.
Web App 2
Web App 3
Active Directory Domain 2
Legacy Application Support – Kerberos/IWA Architecture
Process Flow
1. 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.
Use Cases
36
Access Gateway VAM Best Practices Guide
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 –
NTLM
In 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
Access Gateway VAM Best Practices
https://app1.company.com
https://app2.company.com
https://app3.company.com
User
SecureAuth IdP
1
5
4
Web App 1
2
6
3
External FW
Internet
Internal FW
Access Gateway External Node
Internet
DMZ
Access Gateway Internal Node
Web App 2
LAN
Web App 3
FIGURE 34.
Legacy Application Support – NTLM Architecture
Process Flow
1. 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.
Use Cases
38
Access Gateway VAM Best Practices Guide
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 Protocols
The 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 Flow
1. 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