2.6.8 Protecting Multiple Resources

Figure 2-14 Hierarchical View of Access Gateway Configured Objects

In Figure 2-14, Access Gateway 1 and Access Gateway 2 have the same configuration except for the reverse proxy listening address. They share the other configuration settings because they are members of an Access Gateway cluster. This section explains how to create a group of web servers, how to add multiple proxy services and reverse proxies to an Access Gateway, and how to manage a cluster of Access Gateways.

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

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 Access Gateway. Access Gateway configuration for the test.company.com proxy service contains the information for accessing its web servers (test1.com). Figure 2-15 illustrates this type of configuration for three proxy services.

Figure 2-15 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 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.

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

    sales.company.com

    10.10.195.90:80

    sales.internal.com

    10.10.15.20

    apps.company.com

    10.10.195.90:80

    apps.internal.com

    10.10.15.30

  • Configure your DNS server to resolve the published DNS names to the IP address of 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 Creating a Second Proxy Service, and select domain-based for the multi-homing type.

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, Access Gateway resolves the URL to the sales resource group. Figure 2-16 illustrates this type of configuration.

Figure 2-16 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. 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 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 Access Gateway sends to the web server. 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. 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 2-16 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. 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 2-16 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.

Preparing for Path-Based Multi-Homing

Before configuring 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.10.15.10

    test.com/sales

    10.10.195.90:80

    sales.internal.com

    10.10.15.20

    test.com/apps

    10.10.195.90:80

    apps.internal.com

    10.10.15.30

  • Configure your DNS server to resolve the published DNS names to the IP address of 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 Creating a Second Proxy Service, and select path-based for the multi-homing type.

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 Access Gateway host. Figure 2-17 illustrates this type of configuration.

Figure 2-17 Using Multiple DNS Names

Virtual multi-homing cannot be used with SSL. You must use this configuration with resources that need to be protected, but the information exchanged must 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 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 Access Gateway.

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

Creating a Second Proxy Service

  1. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy].

  2. In the Proxy Service List, select New.

  3. Specify the following details:

    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 Access Gateway must 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 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 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 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 about creating a second reverse proxy, see 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 must contain the name of the back-end web server (Web Server Host Name option) or whether the HTTP header must 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 Access Gateway must 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.

    For iChain administrators, the Web Server Host Name is the alternate hostname when configuring a web server accelerator.

  4. Click OK.

  5. To continue, select one of the following:

Configuring a Path-Based Multi-Homing Proxy Service

To configure a path-based proxy service:

  1. Click Devices > 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 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) 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 3.3.2, Controlling Browser Caching.

  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.

    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 /*, 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, Access Gateway automatically reconfigures to use this new protected resource.

    • If you disable a protected resource that Access Gateway has assigned to a path-based service, 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 to ensure that they meet the requirements for your path-based service.

    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 the protected resource 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, select the name of the parent proxy service, then click Protected Resources.

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

    6. Select an Authentication Procedure.

    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 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 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. Click OK.

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

Setting Up a Group of Web Servers

You can configure a proxy service to service a “virtual” group of web servers, which adds load balancing and redundancy. Each web server in the group must contain the same material. When you create the proxy service, you set up the first server by specifying the URLs you want users to access and the rights the users need for each URL. When you add additional web servers to the proxy service, these servers automatically inherit everything you have configured for the first web server.

Figure 2-18 Adding Redundant Web Servers

For this configuration, you use a single reverse proxy and proxy service. To add multiple web servers to a host:

  1. Click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers.

  2. In the Web Server List section, click New.

  3. Specify the IP address or the fully qualified DNS name of another web server for the “virtual” group, then click OK.

  4. Repeat Step2 and Step3 to add additional web servers to the group.

  5. Click OK.

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

Access Gateway uses the round robin algorithm by default. You can configure it to use the simple failover algorithm.

Simple failover sends all the traffic to the first web server as long as it is available. Traffic is sent to another web server in the list only when the first web server is no longer available. To configure this option, see Configuring TCP Connect Options for Web Servers.

Connection persistence is enabled by default. This allows Access Gateway to send multiple HTTP requests to the web server to be serviced before the connection is closed. To configure this option, see Configuring TCP Connect Options for Web Servers.

Session stickiness option is used if multiple web Servers are configured for a service. Selecting this option makes the proxy server to use the same web server for all fills during a session. This option is enabled by default. For more information about persistent connections, see Configuring Connection and Session Persistence.

Configuring Web Servers at Cluster Level

You can configure web servers at cluster level and view web servers at cluster level in the lag-cluster drop -down list. You can use this option when you want to create web servers at cluster level.

You can sort the web servers in the cluster, add the web servers to the cluster, delete the web servers in the cluster and prioritize the web server list.

  1. Select the group device from the Cluster drop-down list to change the web server ordering.

  2. Click New to add a web server to the cluster or cluster member in the web server List.

  3. Specify the IP address or the fully qualified DNS name of the web server in the Web Server IP Address or DNS number.

  4. Click Delete to delete the web servers at the cluster/cluster member level. A message is displayed as “ If you delete web server from the cluster, then it will be deleted from all cluster members”.

  5. Click Ok to continue or Cancel to discard the changes.

    NOTE:If Access Gateway is configured to use Simple Failover, you can prioritize the web server list at the cluster level and this will reflect the changes in the all the cluster members list. When the web server is configured from cluster member, order cannot be changed from cluster because the order would be different from each cluster member.

Configuring Web Servers at Member Level

You can configure the web servers at the member level by adding and deleting the web servers. You can move up or down the web servers as primary web server. You can add a new web server at the cluster member level.

  1. Click New and enter the Web Server IP Address or DNS number. A confirmation dialog displays the following message”. The web server addition makes this service's web server configuration as member specific. Henceforth the web server ordering must be changed from each cluster member”.

  2. Click OK to continue.

  3. Select the specific web server you ant to delete and click Delete. A message is displayed as "Delete the selected Web Server(s)?". Click OK to continue.

  4. If Access Gateway is configured to use Simple Failover, you can move up or down the web servers as primary web server. To configure Simple Failover, see Configuring TCP Connect Options for Web Servers.

When the web server is deleted a message is displayed as "Web Server Address Changed. All cached content on this Server must be purged. Purge All Cache? " The system will purge the details of the deleted server. Using the arrow key you can configure the web servers as primary web server.

NOTE:The primary web server at the member level is not the same at the cluster level. The web server list sorting will be different at both cluster and member level.

Managing Multiple Reverse Proxies

Each reverse proxy must have a unique IP address and port combination. If your Access Gateway has only one IP address, you must select unique port numbers for each additional reverse proxy that you create. You can configure Access Gateway to use multiple IP addresses. These addresses can be configured to use the same network interface card, or if you have installed multiple network cards, you can assign the IP addresses to different cards.

  • Access Gateway Appliance: To configure IP addresses and network interface cards, see Viewing and Modifying Adapter Settings.

  • Access Gateway Service: You need to use system utilities to configure network interface cards and new IP addresses. After they are configured, you can use the New IP option to make them available for Gateway Service configuration. See Adding a New IP Address to Access Gateway.

If you are creating more than one reverse proxy, you must select one to be used for authentication. By default, the first reverse proxy you create is assigned this task. Depending upon your Access Gateway configuration, you might want to set up one reverse proxy specifically for handling authentication. The authentication reverse proxy is also used for logout. If you have web applications that contain logout options, these options need to be redirected to the Logout URL of the authentication proxy.

Managing Entries in the Reverse Proxy List

  1. Click Devices > Access Gateways > Edit > Reverse Proxy / Authentication.

  2. In the Reverse Proxy List, select one of the following actions:

    • New: To create a new reverse proxy, click New. You are prompted to enter a display name for the proxy. For configuration information, see Section 2.6.3, Managing Reverse Proxies and Authentication.

      Reverse proxy names and proxy service names must be unique to Access Gateway. Protected resource names need to be unique to the proxy service, but they don’t need to be unique to Access Gateway.

    • Delete: To delete a reverse proxy, select the check box next to a specific reverse proxy, then click Delete. To delete all reverse proxies, select the check box next to the Name column, then click Delete.

    • Enable: To enable a reverse proxy, select the check box next to a specific reverse proxy, then click Enable. To enable all reverse proxies, select the check box next to the Name column, then click Enable.

    • Disable: To disable a reverse proxy, select the check box next to a specific reverse proxy, then click Disable. To enable all reverse proxies, select the check box next to the Name column, then click Disable.

  3. Click OK.

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

Changing the Authentication Proxy Service

If you have multiple reverse proxies, you can select the reverse proxy that users are redirected to for login and logout.

IMPORTANT:Changing the reverse proxy that is used for authentication is not a trivial task. For example, if you have customized the logout options on your web servers to redirect the logout request to the Logout URL of the current authentication reverse proxy, you need to modify these options to point to a new Logout URL.

If you have set up SSL connections, you need to change your certificate configurations.

To select the reverse proxy to use for authentication:

  1. Click Devices > Access Gateways > Reverse Proxy / Authentication.

  2. In the Embedded Service Provider section, select a value for the Reverse Proxy option. This is the reverse proxy that is used for authentication.

    The screen is refreshed and the Metadata URL, Health-Check URL, and Logout URL are rewritten to use the selected reverse proxy.

  3. (Conditional) If your Access Gateway certificates were generated by a different certificate authority than your Identity Server certificates, you need to import the trusted root of Identity Server into the trusted root keystore of the Embedded Service Provider. Click Auto-Import Identity Server Configuration Trusted Root, click OK, specify an alias, click OK, then click Close.

    If you don’t know whether you need to import the trusted root, click the option. If the trusted root is already in the keystore, the duplicate key is not imported and you are informed of this condition.

  4. In the Reverse Proxy List, click the name of the reverse proxy that you have selected for authentication.

  5. If you have enabled SSL between the Embedded Service Provider and Identity Server, you need to import the trusted root of the Embedded Service Provider into the trusted root keystore of Identity Server. Click Auto-Import Embedded Service Provider Trusted Root, click OK, specify an alias, click OK, then click Close.

    If you don’t know whether you need to import the trusted root, click the option. If the trusted root is already in the keystore, the duplicate key is not imported and you are informed of this condition.

  6. If you have enabled SSL between the browser and Access Gateway, you need to configure this reverse proxy for SSL. Use the Select Certificate icon to browse for the certificate that matches the DNS name of the proxy service or use the Auto-generate Key option to create a certificate that matches the DNS name of the proxy service.

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

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

  9. (Conditional) If you have customized web logout pages, update them to use the new Logout URL.