17.2 Using Multi-Homing to Access Multiple Resources

You can configure the Access Gateway to use one public IP address to protect multiple types of Web resources. This is one of the major benefits of Access Gateway because it conserves valuable resources such as IP addresses. This feature also makes the 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:

17.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 prepend host names to cookie domain name. For a test resource, you can prepend 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 17-3 illustrates this type of configuration for three proxy services.

Figure 17-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 (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 host name 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 that use company.com as a common domain name and then lists the IP address that these DNS names resolve to and the Web servers they are going to protect.

    Published DNS Name

    Access Gateway IP Address

    Web Server Host Name

    Web Server IP Address

    test.company.com

    10.10.195.90:80

    test.internal.com

    10.15.0.10

    sales.company.com

    10.10.195.90:80

    sales.internal.com

    10.15.0.20

    apps.company.com

    10.10.195.90:80

    apps.internal.com

    10.15.0.30

  • 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.

To create a domain-based multi-homing proxy service, see Section 17.2.4, Creating a Second Proxy Service, and select domain-based for the multi-homing type.

17.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 17-4 illustrates this type of configuration.

Figure 17-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 Remove Path on Fill 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 17-4 have links to the app Web servers or to the test Web servers. If they don’t, you can set the Host Header option to either Forward Received Host Name or to Web Server Host Name. However if they do contain links to each other, you need to set the Host Header option to Web Server Host Name and specify a DNS name for the Web server in the Web Server Host Name 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 17-4 have the same name: www.test.com.

If you select to use the Forward Received Host Name option for a path-based service, you might also need to add entries to the Additional DNS Name List for the rewriter. For more information, see Determining Whether You Need to Specify Additional DNS Names.

Configuring 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:

    Published DNS Name

    Access Gateway IP Address

    Web Server Host Name

    Web Server IP Address

    test.com

    10.10.195.90:80

    test.internal.com

    10.15.0.10

    test.com/sales

    10.10.195.90:80

    sales.internal.com

    10.15.0.20

    test.com/apps

    10.10.195.90:80

    apps.internal.com

    10.15.0.30

  • 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.

To create a path-based multi-homing proxy service, see Section 17.2.4, Creating a Second Proxy Service, and select path-based for the multi-homing type.

17.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 17-5 illustrates this type of configuration.

Figure 17-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 this, you are ready to configure the Access Gateway.

To create a Virtual multi-homing proxy service, see Section 17.2.4, Creating a Second Proxy Service, and select Virtual for the multi-homing type.

17.2.4 Creating a Second Proxy Service

  1. In the Administration Console, click Access Manager > Access Gateways > Edit > [Name of Reverse Proxy].

  2. In the Proxy Service List, select New.

    Configuring a multi-homing proxy service
  3. 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:

    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 (Web Server Host Name option) or whether the HTTP header should contain the published DNS name (the Forward Received Host Name option).

    For a path-based multi-homing service, it is usually best to select the Web Server Host Name 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 Forward Received Host Name, this option is not available.

    NOTE:For iChain® administrators, the Web Server Host Name is the alternate host name when configuring a Web Server Accelerator.

  4. Click OK.

  5. To continue, select one of the following:

17.2.5 Configuring a Path-Based Multi-Homing Proxy Service

To configure a path-based proxy service:

  1. In the Administration Console, click Access Manager > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Path-Based Multi-Homing Proxy Service].

    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.

  2. Configure the following options:

    Description: (Optional) Provides a field where you can describe 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 16.3, Configuring Custom Cache Control Headers, Section 16.2, Controlling Browser Caching, and Section 16.1, Configuring Global Caching Options.

  3. 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 Path List, 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 Remove Path on Fill option.

  4. Determine whether you need to create a protected resource for your path.

    In the Path List, 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.

    1. In the Path List section, click the Protected Resource link.

    2. Examine the contract, Authorization, Identity Injection, and Form Fill policies assigned to this protected resource.

    3. To return to the Path-Based Multi-Homing page, click the Overview tab, then click OK.

      • If the protected resource meets your needs, continue with Step 5

      • If it does not meet your needs, you must create a protected resource for the path-based proxy service. Continue with Step 4.d.

    4. Click OK, the name of the parent proxy service, then Protected Resources.

    5. In the Protected Resource List, click New, specify a name, then click OK.

    6. Assign a contract.

    7. In the URL Path List, 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 which 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.

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

    9. (Optional) Enable the policies the path-based proxy service requires. Click Authorization, Identity Injection, or Form Fill and enable the appropriate policies.

    10. Click OK.

  5. To save your changes to browser cache, click OK.

  6. To apply the changes, click the Access Gateways link, then click Update > OK.