VAM. SecureAuth Access Gateway (SAAG) Value-Added Module (VAM) Deployment Guide

Transcription

1 VAM SecureAuth Access Gateway (SAAG) Value-Added Module (VAM) Deployment Guide

2 Copyright Information SecureAuth is a copyright of SecureAuth Corporation. SecureAuth s IdP software, appliances, and other products and solutions, are copyrighted products of SecureAuth Corporation. Core Security is a copyright information of Core Security Corporation. May, 2018 For information on supporting this product, contact your SecureAuth sales representative: support@secureauth.com Phone: or Website:

3 Table of Contents Introduction... 1 Background... 1 Traditional Role of a DMZ...2 Identity Federation and Identity Management...4 Secure Network Architecture Technology... 5 Eliminating DMZ and Cybersecurity Threats...6 Network Protection...6 Preventing Data Duplication...7 No Front-End Servers...7 Forward Proxy vs. Reverse Proxy... 7 Uses of Reverse Proxy Solution Architecture Topology...11 Key Points Requirements Hardware Requirements...13 Deployment Prerequisites...13 Deployment External Access Gateway Node...14 Internal Access Gateway Node...14 How It Works...15 The Difference between the SecureAuth Access Gateway and a Reverse Proxy Server...16 Security Benefits...19 Layer 3/4 Attack Protection Layer 7 Proxy Features Access Control Thorough Traffic Inspection Universal Authentication and Legacy Application Support Installation and Configuration Deploying the Network...21 Step 1. Deploying the Node Pair Upgrading an Existing Installation...21 Step 2. Configuring the Network Settings Step 3. How to Change Default Passwords Change the Password for CLI Users: saag Change the Password for CLI User: expert Change the Password for a Web Interface User: admin Step 4. How to Log into the Web Interface Step 5. How to Change the Web Admin Password Step 6. How to Configure a New SSL Certificate for Web Interface Access Prerequisites Configure Diffie-Hellman Parameters Configure SSL Ciphers You Want to Use Reserving Firewall Ports... 32

4 Step 7. Configuring SAAG Node Pairs How to Change the Details of a SAAG Node How to Change the Nameservers Step 8. How to Request a License Key Step 9. How to Activate the License Key Step 10. How to Configure and Verify a Rule Step 11. How to Configure the Layer 7 Proxy Prerequisites How to Use the Proxy Configuration Editor Setting Required SecureAuth IdP Post Authentication Values...39 Using DSL and Configuration Recipes DSL Specification...42 Configuration Recipes...45 Single Application Recipe Multiple Application with Subdomains Recipe SSO with NTLM Recipe How to Integrate SAAG and Kerberos Configure the Active Directory Environment...54 Create a Record in the Name of the Target User Create an Active Directory Delegate User Create and Export the Keytab File...57 Configure the Kerberos Integration Recipe...59 Validate the Kerberos Integration...60 Administrative Tasks How to Add Administrators...61 How to Implement High Availability...61 How to Use Logging...62 Syslog Server Web Logs How to Configure a Web Session Timeout...63 Use Cases Basic Use Case...65 Process Flow Identity Assertion Front End...66 Process Flow Features Legacy Application Support, Universal Authentication Kerberos/IWA...67 Process Flow Features Legacy Application Support, Universal Authentication NTLM...69 Process Flow Features Factor Authentication for Non-HTTP Protocols...71 Process Flow Features Troubleshooting Conclusion... 72

5 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. NOTE: Throughout this guide a distinction is maintained between the SecureAuth Gateway VAM itself and the software that is used to configure it. When referring to the overall package, we use the term Access Gateway ; when referring to the software used to configure the access gateway, the term SAAG is used. 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. To begin, there was the firewall. Which seemed a great advance in network security. 1

6 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 W eb 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). Traditional Role of a DMZ Ninety percent of organizations around the world today deploy a DMZ in order to provide customers, partners, 2

7 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 Internal Network 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. To adapt to these challenges, IT departments developed more sophisticated DMZ constructions, like Figure 3: 3

8 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 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 4

9 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 eliminating 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 twotier 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 is relayed to the destination application. If the user is not authenticated, the traffic is relayed to the SecureAuth IdP portal to authenticate and determine identity. DMZ Access Gateway External Node 5

10 Internet 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 the compromise 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 and user 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). 6

11 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 User 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 Gateway Internal Node Access Gateway External Node DMZ Access Gateway Server Internal Network Encrypted DB 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 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. A forward proxy server normally referred to as a proxy server is a server that acts as an intermediary for 7

12 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 I need a price list for sprockets Acme Technology Proxy Spacely Sprockets Here is the price list you requested Here is the price list you requested 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. 8

13 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 Proxy Web Server 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. 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 o pens a port only from the LAN to the DMZ Access Gateway External Access Gateway Internal DMZ Internal Network 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. 9

14 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 which 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 a 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 utilize an agent installed on user systems to ensure a constant connection to a cloud proxy/reverse proxy server. + A reverse proxy can add basic HTTP access authentication to a web server that does not have any authentication. Solution Architecture 10

15 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 User SecureAuth IdP Web App Internet External FW Access Gateway External Node Internal FW Access Gateway Internal Node Web App 2 Internet DMZ 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, 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 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. 11

16 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. The SecureAuth Access Gateway ensures 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. 12

17 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) 4 CPU: 4 virtual RAM: 4 GB Storage: 40 GB Linux 808 and 444 from the Internal Access Gateway node to the external node. Internal node to the back-end application on port 443. Access Gateway Node (External) 2 CPU: 2 virtual RAM: 2 GB Storage: 40 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. 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). Deployment 13

18 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 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 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 NOTE: The Access Gateway nodes operate without the need to open any incoming ports in your organization s internal firewall located between the DMZ and internal LAN. 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. This external node ensures that only legitimate session data can pass through into the LAN. The 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 where the external Access Gateway node is located (before or after the web/application front-ends), the external node s main job is to ensure secure connectivity into the internal network, providing a simple method for moving any user directory (such as Active Directory) and/or database services from the DMZ into the internal LAN. 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 14

19 previously-authenticated sessions, or to SecureAuth IdP for non-authenticated traffic). IP = User IP = IP = Access Gateway External Node Access Gateway Internal Node IP = IP = Application Server DB Server User > Front End Segment S.IP = FW DMZ Inf Front End > Access Gateway External Segment S.IP = D.IP = Access Gateway Internal > Access Gateway External Segment S.IP = D.IP = Access Gateway Internal > App Server Segment S.IP = D.IP = App Server > DB Server Segment S.IP = D.IP = FIGURE 10. Deployment Example How It Works The operation proceeds as follows: 1. A full session is initiated from the internal Access Gateway node to the external Access Gateway node on TCP port Every few milliseconds, the internal Access Gateway node polls for new sessions that have been sent to the external Access Gateway node from external clients. 3. When an incoming request comes in from the Internet, it reaches the external Access Gateway node over the designated service port (such as TCP port 443 for HTTPS traffic), and the external Access Gateway node does the following: a. Strips the key attributes from the request (such as port number, protocol, IP, and URL) b. Verifies the request (for example, port and white/black lists) c. Holds the raw request data in a queue. 15

20 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 is 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 SharePoint 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). As can be seen above, the use of a reverse proxy creates various security and application challenges: Once incoming ports are open in the internal firewall, the DMZ is effectively merged with the internal network. 1. If an external attacker compromises the reverse proxy server, the attacker may also be able to get access into 16

21 the company s internal servers, applications, and internal network. 2. Many 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 User Complexity: Data is duplicated and constantly synched Security Issue #2: Data is stored outside the organization LAN Security Issue #1: Constant incoming hole in the Firewall SharePoint W eb Front-end SharePoint Application Server SharePoint DB Servers DMZ Internal Network 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 + 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

22 5. Once there is a request to handle, the Internal pulls it 4. The request is sent Request User 1. User request flow 2. The request is captured by the External Access Gateway. 3. The Internal Access Gateway is constantly checking for new requests to the Application server Access Gate way External Acces s Gateway In ternal SharePoint Web Front-end DMZ 6. The reply is sent in the same connection. No need for incoming firewall hole Reply SharePoint Application Servers Internal Network SharePoint DB Servers FIGURE 13. Deploying SecureAuth Access Gateway in the Solution 1. Deploy the internal Access Gateway in front of the SharePoint application server. 2. Deploy the external Access Gateway in the DMZ, replacing the SharePoint front-end. The internal Access Gateway constantly monitors the external Access Gateway for new requests. 3. 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. 4. The internal Access Gateway immediately pulls the request into the LAN and sends it to the SharePoint application server. 5. 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. + 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 Cost: Duplicated Application licenses 18

23 User Reduced Cost: No Application licenses and Hardware duplication Reduced Complexity: Complexity: Data is Data duplicated is not duplicated and constantly and synched synched Security Issue #2: Security Issue #2: Data Fixed. No data is stored is stored outside the outside the organization LAN Security Issue #1: Constant Fixed. No open incoming hole in holes the in Firewall the Firewall Access Gateway External Access Gateway Internal SharePoint Web Front-end DMZ FIGURE 14. Advantages of Using Access Gateway in this Example SharePoint Application Servers Internal Network SharePoint DB Servers Security Benefits There are at least four key benefits derived from using SecureAuth Access Gateway technology. Layer 3/4 Attack Protection The main benefit of the Access Gateway s unique technology, which allows passing session data into the internal network without opening any inbound ports on the internal firewall, is that it enables the complete block of any network or Layer 4 based attacks, such as port scans, ICMP scans, SYN floods and other TCP based attacks. Most importantly, the Access Gateway prevents these attacks from occurring at the firewall or in the internal network. The features of this protection include: + Reduces the possibility of successful attacks coming from malicious users on untrusted networks such as the Internet. + Eliminates the need to store sensitive data in the DMZ. + Simplifies adding new back-end services. + Simplifies managing firewalls and the DMZ. + Eliminates the need to open incoming ports in the internal firewall. 19

24 + Eliminates the need to establish direct connections from an untrusted network to specific hosts in the internal network. + Provides substantial cost savings by reducing or eliminating DMZ-based servers, both their physical hardware, OS, and application server licenses. Layer 7 Proxy Features The Layer 7 reverse proxy is an integrated component that provides these features: + Ensures users cannot connect to the requested back-end service until they are authenticated. + Manages multiple internal applications on a single IP address and domain name. + Provides SSL offloading. + Supports the IdP SAML and WS-Fed protocols and adds support for NTLM, Header Authentication, and Post Authentication. + Provides dynamic URL rewriting supporting multiple back-end applications. + Provides transparent access without the need for a VPN/special client. For more on this, refer to Step 11. How to Configure the Layer 7 Proxy on page 38. 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). 20

25 Installation and Configuration After reading the general information contained in Deployment on page 14, it is time to perform the actual installation and configuration. Each step of this procedure is detailed in the following subsections. Deploying the Network Follow these steps to deploy and configure the network. Step 1. Deploying the Node Pair SecureAuth provides two OVA images for deployment of the nodes on VMware infrastructure. You must deploy each Access Gateway node (.OVA file) separately on your virtualization server(s). Deploy the Access Gateway external node in your DMZ and the Access Gateway internal node in your LAN. You can configure the Access Gateway nodes in any order. NOTE: It is assumed the administrator deploying the virtual machines is familiar with the organization s virtual server environment. Obtain from SecureAuth Support the version (or later) patch file. If you have Access Gateway currently deployed on your network, perform an upgrade instead of a new installation. When you perform an upgrade, the existing configuration is automatically migrated to the new Access Gateway version. For more on this, refer to Upgrading an Existing Installation on page 21; otherwise, proceed to Step 2. Configuring the Network Settings on page 22. Additional information on pairing internal and external nodes is explained in Step 7. Configuring SAAG Node Pairs on page 33. Upgrading an Existing Installation To upgrade an existing Access Gateway deployment: 1. Verify the existing reverse-access configuration is working as expected. 2. Perform these steps separately on both the external and internal nodes. a. Power off the VM and create a snapshot. b. Power on the VM. c. Log in as user 'expert'. d. Enter: sudu su, then enter your password when prompted. e. Copy the patch file to the /home/expert directory. f. Enter: tar -xvf <patch_file_name> g. Enter: Cd /tmp/patch 21

26 h. Enter:./patch.rb i. Reboot the virtual machine. j. On the Access Gateway admin web UI, open the management page and verify the version information displays the patch version details. 3. Verify the Access Gateway configuration is working as expected. 4. Perform these steps separately on the Access Gateway external and internal nodes. a. Delete the snapshot if the upgrade VM is working as expected. If it's not, then revert to the VM snapshot. b. If the upgrade VM is working as expected do the following: Delete the patch file. From the /home/expert directory, type: rm -rf tmp Step 2. Configuring the Network Settings The following instructions describe how to configure the external node. You are required to perform these steps separately for both the SAAG external and internal nodes. 1. Open a console and access the external node. A login prompt appears. 2. Enter the user name: saag. A prompt for your password appears. 3. Enter the default password: saag1. You are prompted to change your password. FIGURE 15. Network Setting Login Screen 4. Enter the following: saag1, type your new password, then confirm it. Your new password must satisfy these complexity requirements: Include 10 or more characters Follow at least three out of the following four rules: Include at least one lower case character 22

27 Include at least one upper case character Include at least one number Include at least one special character Once the password is complete, the main network configuration page appears like Figure 16. FIGURE 16. Main Network Configuration Page 5. Select Option 2, Maintenance, to reach the Maintenance menu. A screen like this appears. FIGURE 17. Maintenance Menu 6. Select Option 1, Networking, to reach the Networking Settings menu. 23

28 The Networking Settings menu appears like Figure 18. FIGURE 18. Networking Settings Menu 7. Select Option 2, Edit Existing Network Configurations. A screen like Figure 19 appears. FIGURE 19. Network Editing Screen 8. Select Option 1 then press Enter to insert a new IPv4 address. An entry line appears: FIGURE 20. Edit Entry 9. Enter the new IPv4 address and Press Enter. A screen like Figure 21 appears. FIGURE 21. Edit Type Menu List 24

29 10. Select Option 2, Edit Default Gateway/Route, and the Configure the Default Gateway selection list appears. FIGURE 22. Configure the Default Gateway Screen 11. Select Option 1, Default Gateway. A prompt like Figure 23 appears. FIGURE 23. Default Gateway Entry 12. Enter the New IPv4 Address for the default gateway, then press Enter. The Edit Type menu list reappears as shown in Figure 21 on page Select Option 3, Edit Subnet, and you are prompted to enter an address for the Subnet Mask. 14. Enter in an IPv4 Address for the Subnet Mask, then press Enter. The Edit Type menu list reappears as shown in Figure 21 on page Select Option 4, Save Configurations, once you are done. If everything was configured correctly then a changes were saved message appears. NOTE: For these changes to take effect, the user must go back to the main menu and commit the changes. 16. Select Option 9, Back to Maintenance Menu. You are returned to the Maintenance Menu as shown in Figure 17 on page Select Option 9, Back - Go Back to the main menu. 25

30 The Main Menu reappears. FIGURE 24. Main Menu 18. Select Option 9, Exit, and exit the session. Step 3. How to Change Default Passwords The following instructions describe how to change your default passwords. Perform these steps separately for both of the Access Gateway external and internal nodes. Be sure to change the default passwords for each of these five users: User + saag internal node + saag external node + expert internal node + expert external node admin (Web interface) Default Password saag1 These password changes were previously enforced. rsaccess12345 rsaccess12345 This password change should be done in the web interface. See, Step 5. How To Change The Web Admin Password<XREF>. Change the Password for CLI Users: saag This section describes changing your SAAG password for Command Log In (CLI) users. You should change this password in compliance with your organization s password change policy. NOTE: When you log in for the first time, you are prompted to change your default password. To change your password: 1. Log in using these credentials: User name: saag 26

31 Password: <Your saag password> 2. Navigate to the Maintenance window. FIGURE 25. Maintenance Menu 3. Select 3 then press Enter to display the change password prompt. Please enter your new password: FIGURE 26. Change Password Prompt 4. Enter your current password, a new password, then confirm the new password. Your new password must satisfy these requirements: Include 10 or more characters And at least three out of the following four rules: Include at least one lower case character Include at least one upper case character Include at least one number Include at least one special character Perform the steps above for both the SAAG external and internal nodes. Change the Password for CLI User: expert 1. Log in using these credentials: User name: expert Password: rsaccess At the prompt type: passwd 27

32 Several new lines appear prompting you to enter your current password followed by a new password and a confirmation, as shown in Figure 27. expert@rsaccessext:~$ passwd Changing password for expert. (current) UNIX password: New password: Retype new password: FIGURE 27. Change Password of User: expert 3. Enter the current password, a new password, then confirm the new password. Your new password must satisfy these requirements: Include 10 or more characters And at least three out of the following four rules: Include at least one lower case character Include at least one upper case character Include at least one number Include at least one special character Perform the steps above for both the Access Gateway external and internal nodes. Change the Password for a Web Interface User: admin You should change the web admin password using the web interface as described in Step 5. How to Change the Web Admin Password on page 29. If you are locked out of the web interface, you can connect with a console to the internal node and use the Change Web Password command to change the web admin s password. The administrative user admin can log into the saag web interface to configure the node pair, SSL certificate, rules, proxy configuration, and license key. Step 4. How to Log into the Web Interface The Access Gateway internal node includes a built-in web server that serves the admin web interface. After you configure initial network settings using the CLI, you should perform the remaining configuration tasks with the web interface. When you launch the web interface, you can enter the internal node s host name or IP address. To avoid SSL errors, you should upload a new valid certificate and use the common name specified in the certificate. To log into the SAAG web interface: 28

33 1. In your vcenter server, verify that both virtual machines are powered on. 2. Open a web browser and log into one of these URLs: Name>:3000 or node IP address>: Enter these default values: User name: admin Password: rsaccess12345 If needed, change the default web interface session timeout value from 15 minutes to a different duration. Step 5. How to Change the Web Admin Password This section describes how to change the password for the SAAG web interface admin. You should change the web admin password according to your organization s password change policy. If you ever get locked out of the web interface, you can also change the web admin password using the CLI. To change the web interface admin password: 1. Log into the SAAG web interface. 2. On the Settings web page, click User Management. A screen like the one shown on Figure 28. FIGURE 28. Change Admin Password 3. In the Current Password text box, enter your new password, confirm it, then click Save. Your new password must satisfy these requirements: Include 10 or more characters And at least three out of the following four rules: Include at least one lower case character Include at least one upper case character 29

34 Include at least one number Include at least one special character Step 6. How to Configure a New SSL Certificate for Web Interface Access This section describes how to configure an SSL certificate to enable a secure connection between the SAAG admin web interface and the internal node s web server. Caution: Changing the SSL certificate is recommended but not enforced. The default certificate and key files cannot guarantee the authenticity of the server and you should use them only for testing, not in your production environment. You should replace them with a certificate created by your organization. Prerequisites Generate a new SSL certificate and a key without a passphrase. SAAG supports only X.509 certificates in PEM format. In the SSL certificate s Common Name (CN) field, choose a user-friendly host name. You should also configure the same host name in your organization s Domain Name Server. To configure an SSL certificate for the SAAG web interface: 1. Log into the SAAG web interface. 2. Click Settings > SSL Management to open the Web SSL Management page. 3. Click Select New Certificate to locate your new certificate. 4. Click Open. 5. Click Select New Private Key File to locate your new private key file. 6. Click Open. 7. Click Save & Apply. Configure Diffie-Hellman Parameters The Diffie-Hellman (DH) algorithm provides enhanced forward secrecy for session keys. NOTE: Please ensure that the new DH parameters that you create match your company s policy (if required). This is an example of how to generate DH parameters using OpenSSL: 1. Open a console and log into the internal node s SAAG web interface with the user: expert. 2. Enter this command: openssl dhparam -out dhparam.pem Wait for the parameters to be generated. 30

35 The output should look similar to Figure 29. FIGURE 29. Generated Diffie-Hellman Parameters The DH parameters are automatically saved in a.pem file in the home directory of expert like Figure 30. FIGURE 30. Pem File Containing DH Parameters To upload new Diffie Hellman parameters: 1. Log into the SAAG web interface. 2. Click Settings > SSL Management to open the Web SSL Management page. 3. Click Select New Diffie-Hellman Configuration file. 4. Select the file and then click Open. 5. Click Save & Apply. Configure SSL Ciphers You Want to Use The Web SSL Management page lists ciphers the SAAG web server is configured to use. NOTE: The ciphers are listed with colon (:) separators. 31

36 FIGURE 31. SSL Ciphers When an administrator uses a web browser to connect to the SAAG web server, the client and server negotiate to select the most secure cipher suite they both support. In the Web SSL Management page, you can reorder the priorities of the listed ciphers and add or delete ciphers. 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 firewall 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. 4. Set the ports to dedicated values. The ports generally reserved for this operation are: Rules Internal to external node (outgoing) NOTE: The external node is only open and listening on TLS/SSL port 443. Dedicated Port Number 8888, 8008 Access Gateway tool communications port 3000 SSH communication with the internal node (optional) Save and close the firewall application. 32

37 Step 7. Configuring SAAG Node Pairs This section describes how to configure the network settings of a node pair in the Access Gateway web interface. In the web interface, you name the node pair and enter the network configuration values you previously configured using the CLI. For more information, see, Step 2. Configuring the Network Settings on page 22. To configure the Access Gateway node pair: 1. Log into the SAAG web interface. 2. Click Server Management. NOTE: The Server Management web page is empty until you configure at least one node pair. 3. In the upper left corner of the Server Management web page, click the plus sign (+). The Node Pair Details screen appears like Figure 32. FIGURE 32. Node Pair Details 4. Enter the following values: Pair name Internal Address Create an alias to identify the node pair. Enter the same IP address as the one configured using the CLI. Port Leave the default port: External Address Enter the same IP address as the one configured using the CLI. Port Leave the default port:

38 5. Click Save & Apply to save the configuration and deploy the changes to the virtual machines. A Ping button appears to the right of each completed node configuration. FIGURE 33. Verify Node Ping Buttons 6. Click each node s Ping button to verify that the IP address and port of each node is correct. If successful, this message should appear: Internal/External server ping successful. How to Change the Details of a SAAG Node You can change the IP address and port number of the nodes without deleting the existing pair or requesting a new license. The IP address and port are editable on the Server Management edit pair web page. NOTE: A license is locked to an existing VM. How to Change the Nameservers You can change the nameservers for each node using the interactive shell or the web interface. To change the nameservers using the SAAG web UI: 1. Log into the SAAG web interface. 2. On the Settings web page, enter the IP address you want to add for a node. If you enter an IP address that is already displayed, it is removed. 3. Repeat Step 2 as required. Best practice is to configure a primary and secondary nameserver for each node. 4. Select Update Nameservers to save your changes. Step 8. How to Request a License Key This section describes how to create a request for a SAAG license key. Requesting, receiving, and activating the SAAG license key are all mandatory steps for using the product. To request a SAAG license key: 1. Log into the SAAG web interface. 34

39 2. On the Server Manager web page, click the License tab. The Licenses Management web page appears. 3. Enter the number of rules you want SAAG to support. The number of rules designates the number of IP address and port pairs that SAAG should expose to the untrusted network. 4. Click the Generate License Request button. A window similar to Figure 34 appears. FIGURE 34. Generate License Request Example 5. Copy and paste the entire license into an message and send it to tailoringfrontline@secureauth.com. Step 9. How to Activate the License Key This section describes how you activate the license key you were ed. 35

40 If the license request is approved, you receive a license key in an from product support, tailoringfrontline@secureauth.com. A SAAG license key looks similar to Figure 35. FIGURE 35. License Key Example To activate a SAAG license key: 1. Log into the SAAG web interface. 2. On the Server Manager web page, click the Licenses link. The Licenses Management web page appears. 3. Paste the license you received into the apply license field and click Apply License. A message appears confirming the license is activated. 4. Verify the license and number of rules has been activated by opening the Server Management web page and scrolling to the bottom. The number of rules and validity period appears if your license is activated. FIGURE 36. Verify License Activation Step 10. How to Configure and Verify a Rule This section describes how to configure a reverse access rule. Each rule defines an IP address and port pair that SAAG should expose to the untrusted network. In this section, we configure as an example of how to publish a back-end service. In your production environment, use the FQDN of the back-end service you want to publish. To configure a rule: 1. Verify the IP address, FQDN, and port of the back-end service you want to publish. 2. Change the DNS record for the FQDN of the back-end service to point to the external IP address of the external SAAG node. To test the rule without modifying the DNS record, add a local entry on the host file of your test client computer. 36

41 3. Open a cmd window and ping the service s FQDN. The IP address returned by the ping command should be the IP address of your external node, not the real IP address of the service. 4. Log into the SAAG web interface. 5. On the Server Manager web page, click the Reverse Access Rules tab. The configure rules web page appears. 6. Click Add Rule. A screen like Figure 37 appears. FIGURE 37. Configuration for One Rule 7. Configure the following fields: Rule Name Internal Service Address Internal Service Port External Node Bind Address External Node Bind Port Callback Address Callback Port 8. Click Save & Apply. An alias to identify the rule. The internal IP address of the back-end service that is being published. Use the IP address you noted in Step 1. The internal port number of the back-end service that is being published. Use the port you noted in Step 1. The IP address used by external users for accessing the SAAG external node. If the SAAG external node has only a single IP address, the value of the External Address field can remain at the default The port number used by external users for accessing the SAAG external node. The IP Address used by the SAAG internal node to access the external node. This IP address is needed by the internal node to pull incoming requests from the external node. If SAAG external has only a single IP address, this field can remain at the default The port number used by the SAAG internal node to access the external node. This port number is needed by the internal node to pull incoming requests from the external node. If SAAG external has only a single IP address associated with this rule, this port number must not be the same as the value for the external port. The reverse-access service is unavailable until the change is completed. 37

42 9. Test the rule you configured by opening a web browser and navigating to the FQDN of the service. Verify that you see the web page you requested. The web page is processed using the SAAG reverse access feature. Step 11. How to Configure the Layer 7 Proxy You configure the L7 proxy using the SAAG Domain Specific Language (DSL). The DSL contains all available L7 proxy configurable parameters. For more information, see DSL Specification on page 42. From the DSL, extract the components you want to use and set values for the parameters. To make the configuration task easier, SAAG includes several pre-built recipes: + Single Application Recipe + Multiple Applications with Subdomains Recipe + SSO With Single Application with NTLM Recipe + Kerberos Integration Recipe (for Kerberos-SAAG integrations) For more information, see Using DSL and Configuration Recipes on page 42. NOTE: When you create a configuration, be sure your environment hosts the required technology. Prerequisites Before your site can utilize the L7 proxy, you must create at least one reverse access rule. See Step 10. How to Configure and Verify a Rule on page 36 for more on doing this. To use the rule for a L7 proxy in a live environment, you must update the rule s details in this way: + Update the internal IP address and port to the listening IP address and port of the L7 proxy + If necessary, create a new DNS record for the desired FQDN of the L7 proxy 38

43 How to Use the Proxy Configuration Editor After you create the L7 proxy configuration file, you need to enter it into the system. You can create your configuration using a separate text editor, or you can create it directly in the configuration editor. FIGURE 38. Configuration Editor To edit and activate the proxy configuration file: 1. Log into the SAAG web interface. 2. On the Server Manager web page, click Proxy Rules. The Proxy Rules web page appears. 3. Do one of these: In the edit field, if you used a separate text editor, copy and paste your configuration. If you created the configuration directly within the edit field, skip this step. 4. Click Check Syntax. 5. Click Save & Apply. The L7 proxy service is unavailable until the change is completed. Setting Required SecureAuth IdP Post Authentication Values Before continuing, open your SecureAuth IdP web admin and make changes that 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. 39

44 One of two pathways is available from here, depending on the protocol required for this communication: 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 is 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: d. In the SAML Consumer URL field, type or paste the internal gateway s URL plus specifications like this example: An example of this screen is shown in Figure 39. FIGURE 39. 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%252faccount%252flogin&wct= t20%3a37%3a03z&wreply=https%3a%2f%2fvm-oc1- cd0509%2fwsfed_app%2f 40

45 An example of this screen is shown in Figure 40. FIGURE 40. WSFed Sample Page 5. Save the changes to this section and exit the Web Admin. 41

46 Using DSL and Configuration Recipes The following sections describe how to use the SAAG DSL. The DSL contains all available L7 proxy configuration parameters. This section includes these topics: + DSL Specification + Configuration Recipes DSL Specification This section details the recipe required for using DSL. If a parameter in the DSL has a default value, it is automatically applied and you do not have to explicitly include the parameter in your configuration unless you want to change the default value. If you want to use a parameter, and in the DSL the parameter is not assigned a default value, you must include the parameter in your configuration. If a parameter value appears as <some text>, you must replace all text between the angle brackets with an actual value. NOTE: Do not include duplicate parameters in a configuration unless the description of the parameter in the DSL indicates it is permitted. The recipe for DSL is shown in the following example: general { log_path '/var/log/zakif.log' log_level 'debug' log_rotate_num_files 10 log_rotate_filesize content_type 'text richtext html css javascri pt xml xhtml xslt xjavascript json' # Optional section for general configurations # Use this parameter to override the L7 proxy log location. # The folder must exist prior to changing the log location. # Supports the following logging levels: verbose, debug, info, warn, error, fatal. # Only change this if you are instructed to do so by SecureAuth support. # Determines how many log files to keep before a new file overrides a previous file. # Determines the maximum file size for each of the files in the log rotation. # Based on the content type of the request and response HTML, the L7 proxy determines if rewrites are required or not. # For additional information on rewrites please refer to the rewrite configuration sections below. 42

47 } # End of general section. listener { # Mandatory section. port <specify port number> # The port to listen on must be unique. cert_path '<specify path on # Path to the public certificate used by the L7 SAAG internal here for pem proxy for SSL/TLS. file>' key_path '<specify path on # Path to the private key used by the L7 proxy for SAAG internal here for pem SSL/TLS. file>' key_pass '<specify password # Password for the private key above. string here for pem file>' verify_peer false ca_path '<specify path on SAAG internal here for pem file>' tls1 true tls1_1 true tls1_2 true cipher_string 'ECDHE-ECDSA- CHACHA20-POLY1305:ECDHE-RSA- CHACHA20-POLY1305:ECDHE-ECDSA- AES128-GCM-SHA256:ECDHE-RSA- AES128-GCM-SHA256:ECDHE-ECDSA- AES256-GCM-SHA384:ECDHE-RSA- AES256-GCM-SHA384:DHE-RSA- AES128-GCM-SHA256:DHE-RSA- AES256-GCM-SHA384:ECDHE-ECDSA- AES128-SHA256:ECDHE-RSA-AES128- SHA256:ECDHE-ECDSA-AES128- SHA:ECDHE-RSA-AES256- SHA384:ECDHE-RSA-AES128- SHA:ECDHE-ECDSA-AES256- SHA384:ECDHE-ECDSA-AES256- SHA:ECDHE-RSA-AES256-SHA:DHE- RSA-AES128-SHA256:DHE-RSA- AES128-SHA:DHE-RSA-AES256- SHA256:DHE-RSA-AES256- SHA:AES128-GCM-SHA256:AES256- GCM-SHA384:AES128-SHA256:AES256- SHA256:AES128-SHA:!DSS' upgrade_to_ssl true non_ssl_upgrade_port 80 secure_auth_application { hostname '<FQDN of IdP>' # Enable client-side certificate validation. # When verify_peer is set to true, you must specify the certificate used to validate the client certificate. # If client certificates are signed with more than one certificate, use pem files that contain all relevant signing certificates. # Enable TLS1 Protocol # Enable TLS1.1 Protocol # Enable TLS.1.2 Protocol # SSL ciphers to be used for SSL/TLS # The L7 proxy accepts HTTP traffic and automatically forces a client to upgrade the connection to HTTPS. # If necessary, change the default listener port to a different port. # Mandatory section. # FQDN of public DNS record for L7 proxy. 43

48 is_sub_domain false # Set to true to enable using subdomains for redirection to the IdP and services. The sub_domain parameter becomes mandatory for IdP and services. ip_forward_header { # Optional section use false # Determines whether the original source IP header would be forwarded to IdP and back-end applications. This is relevant when the IdP or target service requires this information. header_name '<specify # The name of the header that would be used to desired header name>' forward the original source IP header. This parameter is mandatory when ip_forward_header is set to true. on_fail abort # When the system is configured to provide the source IP address to the back-end application but the source IP is missing in the request: Default is abort. Continue fails open, and abort fails closed. } # ip_forward_header section end. use_keepalive false # Indicates if HTTP keep_alive should be used or not. keepalive_timeout 30 # Specify timeout in seconds for inactive KeepAlive sessions. Default is 30. cookie_ttl 30 * 60 # Controls session cookie retention period in seconds, default is 30 minutes. first_link_recall false # Redirect user to the original URL used to access SAAG before authentication with the IdP. identity { # Mandatory section including the IdP details. hostname '<specify IDP FQDN # IdP FQDN here>' ip '<specify IP of IdP # IdP IP here>' port '<specify port of the # IdP port IdP here>' ssl false # Indicates whether to use SSL/TLS for communication with the IdP. redirect_path '' # If specified, redirects user to this path on first visit, otherwise uses the path based on the allowed_paths parameter described below. redirect_by_agent { # You can perform redirection based on the type of the user agent. Use true # Use redirect by agent: true or false. agent '<type agent name # For example, Mozilla/5.0. here> ' path '<path to redirect # Redirects users to this path to>' } sso { # Optional section - configure Single-Sign-On for proxy. 44

49 saml_username_field "/ *[name()='trust:requestsecurityt okenresponsecollection']/ *[name()='trust:requestsecurityt okenresponse']/ *[name()='trust:requestedsecurit ytoken']/ *[name()='saml:assertion']/ *[name()='saml:attributestatemen t']/ *[name()='saml:attribute'][3]/ *[name()='saml:attributevalue']" saml_password_field "/ *[name()='trust:requestsecurityt okenresponsecollection']/ *[name()='trust:requestsecurityt okenresponse']/ *[name()='trust:requestedsecurit ytoken']/ *[name()='saml:assertion']/ *[name()='saml:attributestatemen t']/ *[name()='saml:attribute'][4]/ *[name()='saml:attributevalue']" use true # The field in which the username for SSO should be extracted from the XML (xpath). # The field in which the password for SSO should be extracted from the XML (xpath). The saml_password field is not used if you are implementing Kerberos. # Determines whether the proxy provides singlesign-on. Configuration Recipes SecureAuth provides pre-built configuration recipes that make it easy for you to configure the L7 proxy. The recipes enable you to configure the L7 proxy for several common use cases. You can download the L7 configuration recipes as editable text files instead of copying them from this pdf file. The next sections describe in detail how to use the built-in recipes. The following recipes are described: + Single Application Recipe + Multiple Application with Subdomains Recipe + SSO with NTLM Recipe An additional recipe is provided in Configure the Kerberos Integration Recipe on page

50 Single Application Recipe This section describes the single application recipe. The single application recipe enables the L7 proxy to handle service requests to one back-end service. Set appropriate values for each parameter in the recipe then activate them in the admin web interface. The Single Application recipe is shown below: listener { port 443 key_path 'example/example.key' cert_path 'example/ example.cert' key_pass '1234' tls1 tls1_1 tls_2 cipher_string 'EDH+aRSA+AESGCM:EDH+aRSA+AES:DH E-RSA-AES256- SHA:EECDH+aRSA+AESGCM:EECDH+aRSA +AES:ECDHE-RSA-AES256-SHA:ECDHE- RSA-AES128- SHA:RSA+AESGCM:RSA+AES+SHA:DES- CBC3-SHA:-DHE-RSA-AES128- SHA:!aNULL:!eNULL:!LOW:!MD5:!EXP :!PSK:!DSS:!RC4:!SEED:!ECDSA:!AD H:!IDEA' secure_auth_application { hostname 'example.sa.local' identity { hostname 'idp.sa.local' # You can change the port number if needed. # To use your own certificate and private key, use the expert user and upload them to the internal SAAG node on /opt/zakif/cert. # The certificate and key are used to secure the connection between the end-user and the SAAG internal node. # Enter the password for the private key above. # You can select which version of TLS the L7 proxy support by listing any of these options. # cipher_string lists the supported server-side ciphers. You can change the precedence of the ciphers and/or remove any ciphers that are not secure enough for your environment. # The host name is the published host name entered by end-users in their web browsers. The host name should match the common name field specified in the SAAG external node s SSL certificate. # Change the host name parameter in the recipe from the default example.sa.local value to the SAAG external node published host name. # The SecureAuth IdP configuration block. # For each service request, the identity configuration block rewrites the published URL, Example: 'example.sa.local' to 'IdP.sa.local'. # Change to your SecureAuth IdP host name. 46

51 ip ' ' port 443 ssl allowed_paths { default_path '/ SecureAuth1/' } path '/AllowedPath1' path '/AllowedPath2' saml_type 'saml' } service { hostname 'app.sa.local' ip ' ' port 80 ssl false allowed_paths { default_path '/ mydefaultvirtualdir' } } } } path '/allowedpath1/' path '/allowedpath2/' # Replace the recipe s IP address with the IP address of the SecureAuth IdP back-end server that authenticates end-users who are making service requests. # Listening port for the IdP, change it if necessary. # Add the allowed_paths section to control which virtual directories the user can access. # Users are automatically redirected to the default path if they try to access a path that is not allowed. # Use as many path sections as required to define the paths a user can access. # Specify the sign-in protocol you are using for your deployment of SecureAuth IdP; it can be either 'saml' or 'wsfed'. # The service block is for configuring the destination parameters of the back-end server. # Change the recipe s host name and IP address so the service request is sent to the desired server. # Change the port for the back-end application if necessary. # Use SSL for an HTTPS connection between SAAG and the back-end application. However, you can use HTTP by deleting the SSL parameter. # Add the allowed_paths section to control which virtual directories the user can access. # Users are automatically redirected to the default path if they try to access a path that is not allowed. # Use as many path sections as required to define the paths a user can access. 47

52 Multiple Application with Subdomains Recipe This section describes the multiple application recipe. The multiple application recipe enables the L7 proxy to handle service requests to multiple back-end services. This feature is enabled using subdomains for redirection to IdP and various services. Set appropriate values for each parameter in the recipe and then activate it in the admin web interface. The recipe is shown below: listener { port 443 key_path 'example/ example.key' cert_path 'example/ example.cert' key_pass '1234' tls1 tls1_1 tls1_2 cipher_string 'EDH+aRSA+AESGCM:EDH+aRSA +AES:DHE-RSA-AES256- SHA:EECDH+aRSA+AESGCM:EEC DH+aRSA+AES:ECDHE-RSA- AES256-SHA:ECDHE-RSA- AES128- SHA:RSA+AESGCM:RSA+AES+SH A:DES-CBC3-SHA:-DHE-RSA- AES128- SHA:!aNULL:!eNULL:!LOW:!M D5:!EXP:!PSK:!DSS:!RC4:!S EED:!ECDSA:!ADH:!IDEA' secure_auth_application { hostname 'example.sa.local' is_sub_domain true # You can change the port number if needed. # To use your own certificate and private key, use the expert user and upload them to the internal SAAG node on /opt/zakif/cert. # The certificate and key are used to secure the connection between the end-user and the SAAG internal node. # Path to the public certificate used by the L7 proxy for SSL/TLS. # Enter the password for the proxy s private key. # You can select which version of TLS the L7 proxy supports by listing any of these options. # cipher_string lists the supported server-side ciphers. You can change the precedence of the ciphers and/or remove any ciphers that are not secure enough for your environment. # The host name is the published host name entered by end-users in their web browsers. The host name should match the common name field specified in the SAAG external node s SSL certificate. # Change the host name parameter in the recipe from the default example.sa.local value to the SAAG external node published host name. # Set to true to enable using subdomains for redirection to IdP and services. The sub_domain parameter becomes mandatory for IdP and services. 48

53 identity { hostname 'myidpprovider.myidpdomai n.local' sub_domain 'idp.mydomain.com' ip ' ' port 443 ssl true allowed_paths { default_path '/ SecureAuth1/' path '/ AllowedPath1' path '/ AllowedPath2' } saml_type 'saml' } service { hostname 'someotherdomain.local' sub_domain 'app1.mydomain.com' ip ' ' port 80 ssl false allowed_paths { default_path '/ mydefaultvirtualdir' path '/ allowedpath1/' path '/ allowedpath2/' # The SecureAuth IdP configuration block. # For each service request, the identity configuration block rewrites the published URL, Example: 'example.sa.local' to 'IdP.sa.local'. # Change to your SecureAuth IdP host name. # Use subdomains for redirection to IdP and various services. # Replace the recipe s IP address with the IP address of the SecureAuth IdP back-end server that authenticates end-users who are making service requests. # Listening port for the IdP, change it if necessary. # Add the allowed_paths section to control which virtual directories the user can access. # Users are automatically redirected to the default path if they try to access a path that is not allowed. # Use as many path sections as required to define the paths a user can access. # Specify the sign-in protocol you are using for your deployment of SecureAuth IdP which can be either 'saml' or 'wsfed'. # The service block is for configuring the first back-end service. # Change the recipe s host name and IP address so the service request is sent to the desired server. # Change the port for the back-end application if necessary. # Use SSL for an HTTPS connection between SAAG and the back-end application. However, you can use HTTP by deleting the SSL parameter. 49

54 } } service { hostname 'JustanotherDomain.local' sub_domain 'app2.mydomain.com' ip ' ' port 80 ssl false allowed_paths { default_path '/ mydefaultvirtualdir' path '/ allowedpath1/' path '/ allowedpath2/' } } } } # The service block is for configuring the second backend service. # Change the recipe s host name and IP address so the service request is sent to the desired server. # Change the port for the back-end application if necessary. # Use SSL for an HTTPS connection between SAAG and the back-end application. However, you can use HTTP by deleting the SSL parameter. SSO with NTLM Recipe This section describes the SSO with NTLM recipe which enables the L7 proxy to handle SSO service requests using NTLM. Set appropriate values for each parameter in the recipe and then activate it in the admin web interface. The recipe for this use case is shown below: listener { port 443 # You can change the port number if needed. 50

55 key_path 'example/example.key' cert_path 'example/ example.cert' key_pass '1234' tls1 tls1_1 tls1_2 cipher_string 'EDH+aRSA+AESGCM:EDH+aRSA+AES:DH E-RSA-AES256- SHA:EECDH+aRSA+AESGCM:EECDH+aRSA +AES:ECDHE-RSA-AES256-SHA:ECDHE- RSA-AES128- SHA:RSA+AESGCM:RSA+AES+SHA:DES- CBC3-SHA:-DHE-RSA-AES128- SHA:!aNULL:!eNULL:!LOW:!MD5:!EXP :!PSK:!DSS:!RC4:!SEED:!ECDSA:!AD H:!IDEA' secure_auth_application { hostname 'example.sa.local' identity { hostname 'idp.sa.local' ip ' ' port 443 ssl sso { # To use your own certificate and private key use the expert user and upload them to the internal SAAG node on /opt/zakif/cert. # The certificate and key are used to secure the connection between the end-user and the SAAG internal node. # Path to the public certificate used by the L7 proxy for SSL/TLS. # Enter the password for the proxy s private key. # You can select which version of TLS the L7 proxy supports by listing any of these options. # cipher_string lists the supported server-side ciphers. You can change the precedence of the ciphers and/or remove any ciphers that are not secure enough for your environment. # The host name is the published host name entered by end-users in their web browsers. The host name should match the common name field specified in the SAAG external node s SSL certificate. # Change the host name parameter in the recipe from the default example.sa.local value to the SAAG external node published host name. # The SecureAuth IdP configuration block. # For each service request, the identity configuration block rewrites the published URL, Example: 'example.sa.local' to another URL 'IdP.sa.local'. # Change to your SecureAuth IdP host name. # Replace the recipe s IP address with the IP address of the SecureAuth IdP back-end server that authenticates end-users who are making service requests. # Listening port for the IdP, change it if necessary. # The SSO block is for configuring single sign-on. 51

56 saml_username_field "/ *[name()='trust:requestsecurityt okenresponsecollection']/ *[name()='trust:requestsecurityt okenresponse']/ *[name()='trust:requestedsecurit ytoken']/ *[name()='saml:assertion']/ *[name()='saml:attributestatemen t']/ *[name()='saml:attribute'][3]/ *[name()='saml:attributevalue']" saml_password_field "/ *[name()='trust:requestsecurityt okenresponsecollection']/ *[name()='trust:requestsecurityt okenresponse']/ *[name()='trust:requestedsecurit ytoken']/ *[name()='saml:assertion']/ *[name()='saml:attributestatemen t']/ *[name()='saml:attribute'][4]/ *[name()='saml:attributevalue']" use true use_ntlm true } allowed_paths { default_path '/ SecureAuth1/' # The field in which the username for SSO should be extracted from the XML (xpath). # The field in which the password for SSO should be extracted from the XML (xpath) # Set to true. Do not change the default value. # Set to true. Do not change the default value. # Add the allowed_paths section to control which virtual directories the user can access. # Users are automatically redirected to the default path if they try to access a path that is not allowed. } # Use as many path sections as required to define the paths a user can access. saml_type 'wsfed' # Specify the sign-in protocol you are using for your deployment of SecureAuth IdP which can be either 'saml' or 'wsfed'. } service { hostname 'myservice.sa.local' ip ' ' # The service block is for configuring the destination parameters of the back-end server. # Change the recipe s host name and IP address so the service request is sent to the desired server. # Change the port for the back-end application if necessary. # Use SSL for an HTTPS connection between SAAG and the back-end application. However, you can use HTTP by deleting the SSL parameter. 52

57 path>' } } } } port 443 ssl allowed_paths { default_path '/<some 53

58 How to Integrate SAAG and Kerberos This section describes how to integrate Kerberos with the SecureAuth IdP and Access Gateway. The Kerberos integration recipe enables the L7 proxy to broker SAML/WS-Fed to Kerberos authentication. To integrate Access Gateway and Kerberos follow these steps: 1. Configure the Active Directory Environment 2. Create and Export the Keytab File 3. Configure the Kerberos Integration Recipe 4. Validate the Kerberos Integration Each of these steps is detailed in the following subsections. Configure the Active Directory Environment The following instructions describe how to configure the Active Directory (AD) environment. Perform the instructions below with a user who has sufficient privileges to run the commands. NOTE: You might need to adapt these instructions to meet the requirements of your own environment. Consult with your IT department for specific guidance. Create a Record in the Name of the Target User On an AD server that can access a DNS record manager for domains, create a new A record that contains the same hostname as the target username (created in the next step). For example, if the user is saag, then the DNS record would be for a host named saag. The host should reside under the domain record in which the user resides. If the user is saag@sa- dev.local then an A record named saag should be created under sa-dev.local. Create an Active Directory Delegate User In an Active Directory server that can access a user manager for domains, create a service user to be an AD delegate. For this example, we are using saag as the user name, but you can choose any other name. NOTE: Be sure all instances of saag in this guide are replaced with your user name. 54

59 1. Create a user for the AD delegate. FIGURE 41. Create User for AD Delegate 2. Configure the user s password so it never expires. FIGURE 42. Configure Password 3. In the Active Directory server, open a Windows console. 55

60 4. Enter this command: setspn -A saag1 setspn -A saag1 Registering ServicePrincipalNames for CN=saag1,CN=Users,DC=sa-dev,DC=local Updated object 5. Enter this command: setspn -A saag1 setspn -A saag1 Registering ServicePrincipalNames for CN=saag1,CN=Users,DC=sa-dev,DC=local Updated object 6. Validate the above steps by executing this command: setspn -U -l saag1 C:\Users\Administrator>setspn -U -l saag1 Registered ServicePrincipalNames for CN=saag1,CN=Users,DC=sa-dev,DC=local: You should see the following two lines in the output: 7. In the new user s properties window, mark the user for delegation. a. Click the Delegation tab. 56

61 b. Click to select the Trust this user for delegation to any service (Kerberos only) radio button as shown in Figure 43. Click this option FIGURE 43. Configure AD User Delegation Properties 8. Click OK. Create and Export the Keytab File To create and export the keytab file to the appropriate location: 1. Create the keytab files by running these two commands: ktpass -princ -pass <password> -mapuser saag -ptype KRB5_NT_PRINCIPAL -out c:\tmp\saag1.hosts.keytab For the HTTP service, run these commands: ktpass -princ -pass <password> -mapuser saag - ptype KRB5_NT_PRINCIPAL -out c:\tmp\saag1.http.keytab 57

62 2. Verify the files were created in the destination folder: 3. Log in using expert to the internal node SAAG using WinSCP. 4. Upload the keytab files to.../home/expert. 5. Log in using expert to the internal node SAAG using SSH. 6. Move the http keytab file to.../etc/krb5.keytab on the INT SAAG node. sudo mv /home/expert/saag1.http.keytab /etc/krb5.keytab 7. Move the hosts keytab file to.../etc/hosts.keytab on the INT SAAG node. sudo mv /home/expert/saag1.hosts.keytab /etc/hosts.keytab NOTE: The host s keytab is not used in this procedure. It is saved for future use. 8. Create a file under.../etc/krb5.conf and edit it to contain the following details updated to reflect your own environment. [libdefaults] default_realm = SA-DEV.LOCAL [realms] SA-DEV.LOCAL = { kdc = admin_server = } [domain_realm].sa-dev.local = SA-DEV.LOCAL Sa-dev.local = SA-DEV.LOCAL [logging] default = FILE:/var/log/krb5.log kdc = FILE:/var/log/kdc.log 9. Verify that kinit -k t /etc/krb5.keytab http/saag1.sa-dev.local@sa-dev.local runs without asking for a password. 10. Verify that klist output shows at least one valid ticket that resembles the keytab configurations. 58

63 Configure the Kerberos Integration Recipe The following instructions describe how to configure the L7 Proxy for Kerberos integration. Set appropriate values for each parameter in the recipe then activate them using the SAAG admin web client. listener { port 443 key_path 'example/example.key' cert_path 'example/example.cert' key_pass '1234' tls1 tls1_1 tls_2 secure_auth_application { hostname 'example.sa.local' identity { hostname 'idp.sa.local' ip ' ' port 443 ssl true sso { use true # You can change the port number if needed. # To use your own certificate and private key use the expert user and upload them to the internal SAAG node on /opt/zakif/cert. # The certificate and key are used to secure the connection between the end user and the SAAG internal node. # Path to the public certificate used by the L7 proxy for SSL/TLS. # Enter the password for the private key above. # You can select which version of TLS the L7 proxy supports by listing any of these options. # The host name is the published host name entered by end users in their web browsers. The host name should match the common name field specified in the SAAG external node s SSL certificate. # Change the host name parameter in the recipe from the default example.sa.local value to the SAAG external node published host name. # The SecureAuth IdP configuration block. # For each service request, the identity configuration block rewrites the published URL, Example: 'example.sa.local') to another URL 'IdP.sa.local'. # Change to your SecureAuth IdP host name. # Replace the recipe s IP address with the IP address of the SecureAuth IdP back-end server that authenticates end users who are making service requests. # Listening port for the IdP, change it if necessary. # The SSO block is for configuring single signon. # Set to true if you want to use SSO. 59

64 saml_username_field "/ *[name()='trust:requestsecuritytoken ResponseCollection']/ *[name()='trust:requestsecuritytoken Response']/ *[name()='trust:requestedsecuritytok en']/*[name()='saml:assertion']/ *[name()='saml:attributestatement']/ *[name()='saml:attribute'][3]/ *[name()='saml:attributevalue']" kerberos_settings { } } use_kerberos true krb_realm 'sa-dev.local' krb_server ' ' krb_service 'kerberos' krb_protocol 'http' } } allowed_paths { # The field in which the username for SSO should be searched in the XML (xpath). # This block contains settings for integrating Kerberos with the L7 proxy to enable SSO. # Do not change. # Set this to your realm. # Set this to your AD DC. # FQDN of the service. # Do not change. # Add the allowed_paths section to control which virtual directories the user can access. default_path '/SecureAuth1/' # Users are automatically redirected to the default path if they try to access a path that is not allowed. } # Use as many path sections as required to define saml_type 'wsfed' service { } hostname 'app.sa.local' ip ' ' port 80 ssl true Validate the Kerberos Integration Perform the following steps to validate the Kerberos integration: the paths a user can access. # Specify the sign-in protocol you are using for your deployment of SecureAuth IdP which can be either 'saml' or 'wsfed'. # The service block is for configuring the destination parameters of the back-end server. # Change the recipe s host name and IP address so the service request is sent to the desired server. # Change the port for the back-end application if necessary. # Use SSL for an HTTPS connection between SAAG and the back-end application. However, you can use HTTP by deleting the SSL parameter. 1. Open a new web browser, and navigate to the FQDN of the external SAAG node. 2. Log into the SecureAuth IdP with a user who is privileged to access the back-end service. Verify the back-end server enables the user access without requiring login credentials. 60

65 Administrative Tasks The following tasks are commonly employed by the SecureAuth Access Gateway administrator in order to use SAAG most efficiently. These include: + How to Add Administrators + How to Implement High Availability + How to Use Logging + How to Configure a Web Session Timeout How to Add Administrators This section describes how you can add new administrative users. To add new administrators: 1. Log into the SAAG web interface. 2. Click Server Management > Settings. 3. Click Add User. A new empty row appears. 4. Enter a name and password for the administrator as shown in Figure 44. FIGURE 44. Add New Administrator 5. Confirm the password and click Save. How to Implement High Availability This section describes how to implement high availability for SAAG by deploying multiple node pairs behind a load balancer. To implement high availability: 61

66 1. Deploy the SAAG node pair following the steps described in Deploying the Network on page Ensure each node is working as expected. Deploy one or more additional node pairs following the deployment steps. NOTE: For each additional node pair, you must obtain a separate license key. 3. Copy the reverse-access configuration from the original pair to each new pair. 4. Verify the new node pair is working as expected by sending requests to its external node as described in Step 10. How to Configure and Verify a Rule on page Copy and apply the L7 configuration from the original pair to the new pair. 6. Verify the L7 configuration is working. 7. Add more node pairs by following steps 2 to Configure a load balancer ensuring it uses session stickiness. 9. Verify you can connect to the external and internal nodes through the load balancer. How to Use Logging This section describes how you can utilize SAAG logging to gain information about the access gateway s function. Syslog Server If needed, you can send logging details to your organization s syslog server. This option is not enabled by default. NOTE: Sending reverse-access logs to syslog is not currently supported; it will be added in future versions. To configure syslog logging: 1. Log into the SAAG web interface. 2. Under Syslog, select the check box for each source you want to log: FIGURE 45. Configure Syslog Use syslog for proxy use for a Layer 7 proxy 62

67 Use syslog for control daemon use for a control daemon Use syslog for this web interface use for the administrator web interface 3. At the Syslog host text box, enter the syslog host IP address. 4. At the System port text box, enter the syslog host port. 5. Click Save & Apply. Web Logs Web logs are the logging messages that are forwarded to your syslog server when you select the Use syslog for web interface option on the Server Management web page. Administrator web UI events are displayed on the Server Management > Web Logs page like the example shown in Figure 46. NOTE: If you configure logs to be sent to a syslog server, the logs do not appear locally in the web interface. FIGURE 46. Settings > Web Logs How to Configure a Web Session Timeout This section describes how you can change the web session timeout period. The default web interface session timeout period is 15 minutes. 63

68 To change the web session timeout duration: 1. Log into the SAAG web interface. 2. Select Settings > General Settings. A timeout prompt like this appears. FIGURE 47. Web Session Timeout 3. Enter a value for the web interface session timeout value in minutes. 4. Click Save & Apply. A message appears saying the system will restart the web server and redirect you to the login web page. 5. Log in again for the timeout duration changes to take effect. 64

69 Use Cases This section provides several use cases for the Access Gateway. These use cases include: + Basic Use Case on page 65 + Identity Assertion Front End on page 66 + Legacy Application Support, Universal Authentication Kerberos/IWA on page 67 + Legacy Application Support, Universal Authentication NTLM on page Factor Authentication for Non-HTTP Protocols on page 71 Basic Use Case This use case presents the essential interplay of assertions and authentications that must occur in order for the Access Gateway to enable access between a user and an application. FIGURE 48. Basic Use Case Process Flow The process flow shown in this figure is: 1. A user sends a request with a certain host name, which is set in the proxy rules, and this request is picked up by the Access Gateway external node. 65

70 2. This request is then pulled to the internal node on an outbound connection by the relevant port for each configured rule. This process is repeated for each user request sitting on the Access Gateway external node. 3. On the first request to the internal node, the internal node creates an individual cookie session where the authentication parameter is set to False. Based on the configuration of the rules, the Access Gateway internal node checks to see where the request should be redirected. 4. If there is no valid assertion, the Access Gateway internal node forwards the request to the IdP. The IdP host name is masked by the Access Gateway and its host name is set to the host name of the Access Gateway external node. There is no time during which the IdP s host name is visible to the end users. 5. The IdP authenticates the user to which the cookie on the Access Gateway internal node gets updated and the authentication value is set to True. At the next request, the Access Gateway internal node reverseproxies the user to the back-end application with the assertion made from the IdP. However, the back-end service s host name is again masked by the Access Gateway, and its host name is set to the host name of the Access Gateway external node. This response is then returned to the client. 6. If a valid identity assertion already exists, the Access Gateway reverse-proxies to the web application directly in a single session, and the cookie is destroyed when the transaction is complete. This skips Steps 4 and 5 and goes directly from Step 3 to Step 6. Identity Assertion Front End This use case is designed for securing SAML/WS-Fed applications with a standard SecureAuth IdP setup. User SecureAuth IdP Web App Internet External FW Access Gateway External Node Internal FW Access Gateway Internal Node Web App 2 Internet DMZ LAN Web App 3 FIGURE 49. Identity Assertion Front End Architecture 66