6.2 Using Multi-Homing to Access Multiple Resources
You can configure an Access Gateway to use one public IP address to protect multiple types of Web resources. This is one of the major benefits of the Access Gateway, because it conserves valuable resources such as IP addresses. This feature also makes an Access Gateway a multi-homing device because it becomes a single endpoint supporting multiple back-end resources.
You can select to use only one multi-homing method, or you can use multiple methods. Select the methods that meet the needs of your network and the resources you are protecting. The first proxy service configured for a reverse proxy is always configured to use the DNS name of the Access Gateway. Subsequent proxy services can be configured to use one of the following methods:
This section describes these multi-homing methods, then explains the following:
6.2.1 Domain-Based Multi-Homing
Domain-based multi-homing is based on the cookie domain. For example, if you have a cookie domain of company.com, you can prefix hostnames to a cookie domain name. For a test resource, you can prefix test to company.com and have test.company.com resolve to the IP address of the Access Gateway. The Access Gateway configuration for the test.company.com proxy service contains the information for accessing its Web servers (test1.com). Figure 6-3 illustrates this type of configuration for three proxy services.
Figure 6-3 Using a Base Domain Name with Host Names
Domain-based multi-homing has the following characteristics:
-
If you are using SSL, the back-end servers can all listen on the same SSL port (the default for HTTPS is 443).
-
If you are using SSL, the back-end servers can share the same SSL certificate. Instead of using a specific hostname in the SSL certificate, the certificate can use a wildcard name such as *.company.com, which matches all the servers.
Before configuring the Access Gateway, you need to complete the following:
-
Create the published DNS names with a common domain name for public access to the back-end resources. For example, the table below lists three DNS names that use company.com as a common domain name, lists the IP address that these DNS names resolve to, and the Web servers they protect.
-
Configure your DNS server to resolve the published DNS names to the IP address of the Access Gateway.
-
Set up the back-end Web servers.
-
Create three proxy services for these published DNS names.
To create a domain-based multi-homing proxy service, see Section 6.2.4, Creating a Second Proxy Service, and select domain-based for the multi-homing type.
6.2.2 Path-Based Multi-Homing
Path-based multi-homing uses the same DNS name for all resources, but each resource or resource group must have a unique path appended to the DNS name. For example, if the DNS name is test.com, you would append /sales to test.com. When the user enters the URL of www.test.com/sales, the Access Gateway resolves the URL to the sales resource group. Figure 6-4 illustrates this type of configuration.
Figure 6-4 Using a Domain Name with Path Elements
Path-based multi-homing has the following characteristics:
-
It is considered to be more secure than domain-based multi-homing, because some security experts consider wildcard certificates less secure than a certificate with a specific hostname.
-
Each resource or group of resources must have a unique starting path.
-
JavaScript applications might not work as designed if they obscure the URL path. The Access Gateway needs access to the URL path, and if it is obscured, the path cannot be resolved to the correct back-end resource.
-
The protected resources for each path-based child come from the parent proxy service.
The following sections explain how to configure path-based proxy services and your network so that the Access Gateway can find the correct protected resources:
Configuring the Remove the Path on Fill Option
If the path that is part of the published DNS name (/sales or /apps) is used to identify a resource but is not part of directory configuration on the Web server, the path needs to be removed from the URL before the request is sent to the Web server. For example, suppose you use the following configuration:
|
Browser URL Using the Published DNS Name |
Web Server URL |
|---|---|
|
http://www.test.com/sales |
http://sales4.internal.com/ |
In this case, the path needs to be removed from the URL that the Access Gateway sends to the Web server. The Access Gateway does not allow you to set up multiple paths to this type of Web server, so all pages must have the same authentication requirements.
If the path in the published DNS name is a path on the Web server, the path needs to be passed to the Web server as part of the URL. For example, suppose you use the following configuration:
|
Browser URL Using the Published DNS Name |
Web Server URL |
|---|---|
|
http://www.test.com/sales |
http://sales4.internal.com/sales |
Because the path component specifies a directory on the Web server where the content begins, you need to select to include the path. The Access Gateway then includes the path as part of the URL it sends to the Web server. This configuration allows you to set up multiple paths to the Web server, such as
-
sales/payroll
-
sales/reports
-
sales/products
Such a configuration also allows you to set up different authentication and authorization requirements for each path.
Configuring the Host Header Option
When you create path-based proxy services and also enable the option, you need to know what types of links exist on the Web servers. For example, you need to know if the sales Web servers in Figure 6-4 have links to the app Web servers or to the test Web servers. If they don’t, you can set the option to either or to . However, if they do contain links to each other, you need to set the option to and specify a DNS name for the Web server in the option. The Access Gateway needs a method to distinguish between the Web servers other than the path, because after the path is removed, all the Web servers in Figure 6-4 have the same name: www.test.com.
If you select to use the option for a path-based service, you might also need to add entries to the for the rewriter. For more information, see Determining Whether You Need to Specify Additional DNS Names.
Preparing for Path-Based Multi-Homing
Before configuring the Access Gateway, you need to complete the following:
-
Create the published DNS names with paths for public access to the back-end resources. For example, the table below uses test.com as the domain name. It lists three published DNS names (two with paths), the IP address these names resolve to, and the Web servers that they are going to protect:
-
Configure your DNS server to resolve the published DNS names to the IP address of the Access Gateway.
-
Set up the back-end Web servers. If they have links to each other, set up DNS names for the Web servers.
-
Create one proxy service that uses test.com as its published DNS name and two path-based proxy services.
To create a path-based multi-homing proxy service, see Section 6.2.4, Creating a Second Proxy Service, and select path-based for the multi-homing type.
6.2.3 Virtual Multi-Homing
Virtual multi-homing allows you to use DNS names from different domains (for example test.com and sales.com). Each of these domain names must resolve to the Access Gateway host. Figure 6-5 illustrates this type of configuration.
Figure 6-5 Using Multiple DNS Names
Virtual multi-homing cannot be used with SSL. You should use this configuration with resources that need to be protected, but the information exchanged should be public information that does not need to be secure. For example, you could use this configuration to protect your Web servers that contain the catalog of your shipping products. It isn’t until the user selects to order a product that you need to switch the user to a secure site.
Whether a client can use one DNS name or multiple DNS names to access the Access Gateway depends upon the configuration of your DNS server. After you have configured your DNS server to allow multiple names to resolve to the same IP address, you are ready to configure the Access Gateway.
To create a virtual multi-homing proxy service, see Section 6.2.4, Creating a Second Proxy Service, and select for the multi-homing type.
6.2.4 Creating a Second Proxy Service
-
In the Administration Console, click > > > .
-
In the , select .
-
Fill in the fields.
Proxy Service Name: Specify a display name for the proxy service. For the sales group, you might use sales. For the group of application servers, you might use apps.
Multi-Homing Type: Specify the multi-homing method that the Access Gateway should use to identify this proxy service. Select one of the following:
-
Domain-Based: Uses the published DNS name (www.test.com) with a hostname (www.newsite.test.com). For more information, see Section 6.2.1, Domain-Based Multi-Homing.
-
Path-Based: Uses the published DNS name (www.test.com) with a path (www.test.com/path). For more information, see Section 6.2.2, Path-Based Multi-Homing.
-
Virtual: Uses a unique DNS name (www.newsite.newcompany.com). Virtual multi-homing cannot be used with SSL. For more information, see Section 6.2.3, Virtual Multi-Homing. If you need a unique DNS name and SSL, you need to create a reverse proxy rather than a proxy service. For information on creating a second reverse proxy, see Section 6.3, Managing Multiple Reverse Proxies.
Published DNS Name: Specify the DNS name you want the public to use to access your site. This DNS name must resolve to the IP address you set up as the listening address. This option is not available when path-based multi-homing is selected.
Path: Specify the path to use for this proxy service. This option is available only when path-based multi-homing is selected.
Web Server IP Address: Specify the IP address of the Web server you want this proxy service to manage.
Host Header: Specify whether the HTTP header should contain the name of the back-end Web server ( option) or whether the HTTP header should contain the published DNS name (the option).
For a path-based multi-homing service, it is usually best to select the option. For more information, see Configuring the Host Header Option.
Web Server Host Name: Specify the DNS name of the Web server that the Access Gateway should forward to the Web server. If you have set up a DNS name for the Web server and the Web server requires its DNS name in the HTTP header, specify that name in this field. If you selected , this option is not available.
For iChain administrators, the is the alternate hostname when configuring a Web Server Accelerator.
-
-
Click .
-
To continue, select one of the following:
-
To configure a virtual or domain-based proxy service, see Section 1.1.2, Configuring a Proxy Service.
-
To configure a path-based proxy service, see Section 6.2.5, Configuring a Path-Based Multi-Homing Proxy Service.
-
6.2.5 Configuring a Path-Based Multi-Homing Proxy Service
To configure a path-based proxy service:
-
In the Administration Console, click > > > > .
The following fields display information that must be configured on the parent proxy service (the first proxy service created for this reverse proxy).
Published DNS Name: Displays the value that users are currently using to access this proxy service. This DNS name must resolve to the IP address you set up as a listening address on the Access Gateway.
Cookie Domain: Displays the domain for which the cookie is valid. The Web server that the user is accessing must be configured to be part of this domain.
-
Configure the following options:
Description: (Optional) Provide a description of the purpose of this proxy service or specify any other pertinent information.
HTTP Options: Determines how the proxy service handles HTTP headers and caching. For more information, see Section 5.3, Configuring Custom Cache Control Headers and Section 5.2, Controlling Browser Caching.
Advanced Options: (Access Gateway Service) See Section 6.2.6, Configuring Advanced Options for Path-Based Multi-Homing.
-
Configure the path options:
Remove Path on Fill: Determines whether the multi-homing path is removed from the URL before forwarding it to the Web server. If the path is not a directory at the root of the Web server, the path must be removed. If this option is selected, the path is stripped from the request before the request is sent to the Web server.
If you enable this option, this proxy service can protect only one path. If you have configured multiple paths in the , you cannot enable this option until you have deleted all but one path.
Reinsert Path in “set-cookie” Header: Determines whether the path is inserted into the Set-Cookie header. This option is only available if you enable the option.
-
Determine whether you need to create a protected resource for your path.
In the , the path you specified is listed along with the protected resource that best matches its path.
The Access Gateway automatically selects the protected resource that is used with the specified path. It selects the current protected resource whose URL path most closely matches the specified path.
-
If you have a protected resource with a URL path of /*, the Access Gateway selects that resource unless you have configured a protected resource that has a URL path that more closely matches the path specified on this page.
-
If you add a protected resource at a future time and its URL path more closely matches the path specified on this page, the Access Gateway automatically reconfigures to use this new protected resource.
-
If you disable a protected resource that the Access Gateway has assigned to a path-based service, the Access Gateway automatically reconfigures and selects the next protected resource that most closely matches the path specified on this page.
-
In the section, click the link.
-
Examine the contract, Authorization, Identity Injection, and Form Fill policies assigned to this protected resource to ensure that they meet the requirements for your path-based service.
-
To return to the Path-Based Multi-Homing page, click the tab, then click .
-
Click , select the name of the parent proxy service, then click .
-
In the , click , specify a name, then click .
-
Select an Authentication Procedure.
-
In the , specify the path you used when creating the path-based proxy service. For example, if your path was /apps, specify /apps/* or /apps in the URL Path List.
IMPORTANT:If you create multiple protected resources that exactly match the path-based multi-homing service, there is no guarantee that a specific protected resource will be used. For example, if you create protected resources for both of the paths specified above (/apps and /apps/*) and you have a path-based service with a path of /apps, either of these protected resources could be assigned to this path-based service in the Administration Console or used when access is requested.
-
Make sure the protected resource you created is enabled. If the resource is disabled, it does not appear in the Path List for the path-based proxy service.
-
(Optional) Enable the policies the path-based proxy service requires. Click , , or and enable the appropriate policies.
-
Click .
-
-
To save your changes to browser cache, click .
-
To apply the changes, click the link, then click > .
6.2.6 Configuring Advanced Options for Path-Based Multi-Homing
(Access Gateway Service) If the proxy service is protecting a WebDAV application, you need to configure the advanced option.
-
In the Administration Console, click > > > > > .
-
Configure the following option:
#NAGChildOptions WebDav=/Path: Allows the proxy service to handle the specified path. Remove the pound (#) symbol and replace /Path with the path you want the proxy service to handle.