3.8 Protecting Web Resources Through the Access Gateway

The Access Gateway is a reverse proxy server (protected site server) that restricts access to Web-based content, portals, and Web applications that employ authentication and access control policies. It also provides single sign-on to multiple Web servers and Web applications by securely providing the credential information of authenticated users to the protected servers and applications. The Access Gateway lets you simplify, secure, and accelerate your Internet business initiatives.

This section describes the following tasks:

3.8.1 Configuration Options

A typical Access Manager Appliance configuration includes an Identity Server with LDAP directories and an Access Gateway with a protected Web server. Figure 3-3 illustrates the process flow that allows an authorized user to access the protected resource on the Web server.

Figure 3-3 Accessing a Web Resource

  1. The user requests access to a resource protected by the Access Gateway.

  2. The Access Gateway redirects the user to the Identity Server, which prompts the user for a username and password.

  3. The Identity Server verifies the username and password against an LDAP directory (eDirectory, Active Directory, or Sun ONE).

  4. The Identity Server returns an authentication success to the browser and the browser forwards the resource request to the Access Gateway.

  5. The Access Gateway verifies that the user is authenticated and retrieves the user’s credentials from the Identity Server.

  6. The Access Gateway uses an Identity Injection policy to insert the basic authentication credentials in the HTTP header of the request and sends it to the Web server.

  7. The Web server grants access and sends the requested page to the user.

When you are setting up the Access Gateway to protect Web resources, you create and configure reverse proxies, proxy services, and protected resources. The following figure illustrates the hierarchy of these modules and the major configuration tasks you perform on each module.

Figure 3-4 Access Gateway Modules and Their Configuration Options

This hierarchy allows you to have precise control over what is required to access a particular resource, and also allows you to provide a single sign-on solution for all the resources protected by the Access Gateway. The authentication contract, authentication procedure, Authorization policy, Identity Injection policy, and Form Fill policy are configured at the resource level so that you can enable exactly what the resource requires. This allows you to decide where access decisions are made:

  • You can configure the Access Gateway to control access to the resource.

  • You can configure the Web server for access control and configure the Access Gateway to supply the required information.

  • You can use the first method for some resources and the second method for other resources or use both methods on the same resource.

3.8.2 Managing Reverse Proxies and Authentication

A reverse proxy acts as the front end to your Web servers on your Internet or intranet and off-loads frequent requests, thereby freeing up bandwidth. The proxy also increases security because the IP addresses of your Web servers are hidden from the Internet.

To create a reverse proxy, you must create at least one proxy service with a protected resource. You must supply a name for each of these components. Reverse proxy names and proxy service names must be unique to the Access Gateway because they are configured for global services such as IP addresses and TCP ports. For example, if you have a reverse proxy named products and another reverse proxy named library, only one of these reverse proxies can have a proxy service named corporate.

Protected resource names need to be unique to the proxy service, but they don’t need to be unique to the Access Gateway because they are always accessed through their proxy service. For example, if you have a proxy service named account and a proxy service named sales, they both can have a protected resource named public.

The first reverse proxy and proxy service you create are automatically assigned to be the authenticating proxy.

  1. In the Administration Console, click Devices > Access Gateways > Edit.

    The Edit link is either for a single Access Gateway or for a cluster of Access Gateways.

  2. Click Reverse Proxy / Authentication.

  3. (Conditional) If you have already created at least one reverse proxy, you can view the Embedded Service Provider options and configure some of them:

    Reverse Proxy: Specifies which proxy service is used for authentication. If you have configured only one proxy service, only one appears in the list and it is selected. If you change the reverse proxy that is used for authentication, certificates must be updated to match this new configuration.

    Metadata URL: Displays the location of the metadata.

    Health-Check URL: Displays the location of the health check.

    Logout URL: Displays the URL that you need to use for logging users out of protected resources. This value is empty until you have created at least one reverse proxy and it has been assigned to be used for authentication. If you create two or more reverse proxies, you can select which one is used for authentication, and the logout URL changes to match the assigned reverse proxy.

    If any of your protected resources have a logout page or button, you need to redirect the user’s logout request to the page specified by this URL. The Access Gateway can then clear the user’s session and log the user out of any other resources that have been enabled for single sign-on. If you do not redirect the user’s logout request, the user is logged out of one resource, but the user’s session remains active until inactivity closes the session. If the user accesses the resource again before the session is closed, single sign-on reauthenticates the user to the resource, and it appears that the logout did nothing.

    ESP Global Options: Allows you to configure global options for ESP. For more information, see Configuring ESP Global Options.

    Auto-Import Identity Server Configuration Trusted Root: Allows you to import the public key from the Identity Server cluster into the trust store of the Embedded Service Provider. This sets up a trusted SSL relationship between the Embedded Service Provider and the Identity Server. This option is not available until you have selected an Identity Server Cluster and have configured the use of SSL on the Embedded Service Provider of the reverse proxy that is performing authentication (see the Enable SSL with Embedded Service Provider option on the Reverse Proxy page).

    If the Identity Server cluster is using a certificate created by the Access Manager certificate authority (CA), the public key is automatically added to this trust store, so you do not need to use this option. If the Identity Server cluster is using a certificate created by an external CA, you need to use this option to import the public key into the trust store.

  4. (Optional) Configure the proxy settings:

    Behind Third Party SSL Terminator: Enable this option if you have installed an SSL terminator between the users and the Access Gateway. This allows the terminator to handle the SSL traffic between the browsers and the terminator. The terminator and the Access Gateway can use HTTP for their communication.

    Enable Via Header: Enables the sending of the Via header to the Web server. The Via header contains the DNS name of the Access Gateway and a device ID. It has the following format:

    Via: 1.1 www.mymag.com (Access Gateway-ag-BFBA9849520DB63B-5)

    Deselect this option when your Web server does not need this information or does not know what to do with it.

  5. (Optional) Configure the cookie settings:

    For more information and other options for securing Access Manager cookies, see Enabling Secure Cookies.

    Enable Secure Cookies: Enabling this option sets secure keyword on HTTPS request. If you have enabled the Behind Third Party SSL Terminator option and also enabled the Enable Secure Cookies option, the secure keyword on HTTP and HTTPS requests are set.

    WARNING:Do not enable the Enable Secure Cookies option if you have both HTTP and HTTPS reverse proxies. The HTTP services become unavailable because authentication requests to the non-HTTP services fail.

    Force HTTP-Only Cookie: Forces the Access Gateway to set the HttpOnly keyword, which prevent scripts from accessing the cookie. This helps protect browsers from cross-site scripting vulnerabilities that allow malicious sites to grab cookies from a vulnerable site. The goal of such attacks might be to perform session fixation or to impersonate the valid user.

    IMPORTANT:The HttpOnly keyword can prevent applets from loading and can interfere with JavaScript. Do not enable this option if you have the Access Gateway protecting applications that download applets or use JavaScript.

  6. To create a proxy service, continue with Creating a Proxy Service.

Creating a Proxy Service

  1. In the Administration Console, click Devices > Access Gateways > Edit > Reverse Proxy / Authentication.

  2. In the Reverse Proxy List, click New, specify a display name for the reverse proxy, then click OK.

  3. Enable a listening address. Fill in the following fields:

    Cluster Member: (Available only if the Access Gateway is a member of a cluster.) Select the server you want to configure from the list of servers. The Listening Address(es) and TCP Listen Options modifications apply to the selected server. Modifications made to any other options on the page apply to all servers in the cluster.

    Listening Address(es): Displays a list of available IP addresses. If the server has only one IP address, only one is displayed and it is automatically selected. If the server has multiple addresses, you can select one or more IP addresses to enable. You must enable at least one address by selecting its check box.

    If the Access Gateway is in a cluster, you must select a listening address for each cluster member.

    TCP Listen Options: Provides options for configuring how requests are handled between the reverse proxy and the client browsers. You cannot set up the listening options until you create and configure a proxy service. For information about these options, see Configuring TCP Listen Options for Clients.

  4. Configure the listening ports:

    Non-Secure Port: Specifies the port on which to listen for HTTP requests; the default port for HTTP is 80. Depending upon your configuration, this port might also handle other tasks. These tasks are listed to the right of the text box.

    Secure Port: Specifies the port on which to listen for HTTPS requests; the default port for HTTPS is 443.

    For information about the SSL options, see Configuring the Access Gateway for SSL.

  5. In the Proxy Service List section, click New.

    The first proxy service of a reverse proxy is considered the master (or parent) proxy. Subsequent proxy services can use domain-based, path-based, or virtual multi-homing, relative to the published DNS name of the master proxy service. If you are creating a second proxy service for a reverse proxy, see Using Multi-Homing to Access Multiple Resources.

  6. Fill in the fields:

    Proxy Service Name: Specify a display name for the proxy service, which the Administration Console uses for its interfaces.

    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.

    Web Server IP Address: Specify the IP address of the Web server you want this proxy service to manage. You can specify additional Web server IP addresses by clicking the Web Server Addresses link when you have finished creating the proxy service.

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

    Web Server Host Name: Specify the DNS name of the Web server that the Access Gateway must forward to the Web server. If you have set up a DNS name for the Web server and it requires its DNS name in the HTTP header, specify that name in this field. If the Web server has absolute links referencing its DNS name, include this 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 hostname when configuring a Web Server Accelerator.

  7. Click OK.

  8. Continue with Configuring a Proxy Service or select one of the following tasks:

Configuring a Proxy Service

A reverse proxy can have multiple proxy services, and each proxy service can protect multiple resources. You can modify the following features of the proxy service:

  • Web servers

  • HTML rewriting

  • Logging

  • Protected resources

  • Caching

  1. To configure a proxy service, click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service].

  2. Fill in the following fields:

    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. You must modify this field only if you have modified the DNS name you want users to use to access this resource.

    This name determines the possible values of the Cookie Domain.

    Description: (Optional). Provides a field where you can describe the purpose of this proxy service or specify any other pertinent information.

    Cookie Domain: Specifies the domain for which the cookie is valid.

    If one proxy service has a DNS name of www.support.novell.com and the second proxy service has a DNS name of www.developernet.novell.com, the cookie domains are support.novell.com for the first proxy service and developernet.novell.com for the second proxy service. You can configure them to share the same cookie domain by selecting novell.com for each proxy service. Single sign-on between the proxy services is simplified when the proxy services share the same cookie domain.

    HTTP Options: Allows you to set up custom caching options for this proxy service. See Controlling Browser Caching.

    Advanced Options: Access Gateway Service) Specifies how the proxy service handles specific conditions, such as Web server error pages. If similar options are configured globally, the proxy service configuration overwrites the global setting. For configuration information on the proxy service options, see Configuring the Advanced Options for a Domain-Based and Path-Based Multi-Homing Proxy Service.

  3. Click OK to save your changes to browser cache.

  4. Click Devices > Access Gateways.

  5. To apply your changes, click Update > OK.

    Until this step, nothing has been permanently saved or applied. The Update status pushes the configuration to the server and writes the configuration to the configuration data store. When the update has completed successfully, the server returns the status of Current.

    To save the changes to the configuration store without applying them, do not click Update. Instead, click Edit. On the Configuration page, click OK. The OK button on this pages saves the cached changes to the configuration store. The changes are not applied until you click Update on the Access Gateways page.

  6. Update the Identity Server to accept the new trusted relationship. Click Identity Servers > Update.

  7. Continue with one of the following.

    • If the Web server that contains the resources you want to protect does not use the standard HTML port (port 80), you need to configure the Web server. See Configuring Web Servers of a Proxy Service.

    • Until you configure a protected resource, the proxy service blocks access to all services on the Web server. To configure a protected resource, see Configuring Protected Resources.

Modifying the DNS Setting for a Proxy Service

  1. Get the SSL certificate for the new DNS name.

    For more information, see Section 11.0, Creating Certificates.

  2. In the Administration Console, click Devices > Access Gateways.

  3. Edit AG-Cluster and click on any reverse proxy listed under Reverse Proxy/Authentication.

  4. Change the Server Certificate to the new one for your new DNS name.

    Ignore any warning displayed about CN name mismatch because the proxy service is not yet updated.

  5. Under the Proxy Service List tab, click the proxy which DNS name you want to modify.

  6. Change the Published DNS Name for the proxy service.

    NOTE:Changing the published DNS name of the master proxy changes the Identity Server’s base URL also.

  7. Click OK > OK.

  8. The Cluster Configuration page is displayed.

  9. Click Network Settings > Hosts > IP address of your system.

  10. Add the new DNS name in the list of host names.

  11. Click OK.

  12. Go to Access Gateway.

  13. Click Update All.

  14. When the Access Gateway Health turns green, check the Identity Server Health and ensure that it is green as well.

Configuring ESP Global Options

When you configure an ESP global option, it gets applied to all Access Gateway ESPs in an Access Gateway cluster.

By default, these options are disabled. To enable these options, you need to remove the pound (#) symbol before it and set a value. After you configure an option, you cannot delete it. However, you can disable it again by adding the pound (#) symbol before it. If you have set a value for an option and want to disable the option, you need to add # before the configured option. After saving the changes, the value for the option is set to the default value. For example, if you have set the value for CLUSTER_COOKIE_DOMAIN as CLUSTER_COOKIE_DOMAIN .example.com, add # before CLUSTER_COOKIE_DOMAIN .example.com. After the changes are applied, the option is set to the default value as #CLUSTER_COOKIE_DOMAIN.

NOTE:Access Manager 4.2 onwards, configuring the following options through files is deprecated. You must configure these option by using the Administration Console.

Perform the following steps to configure ESP global options:

  1. In the Administration Console, click Devices > Access Gateways > Edit > Reverse Proxy / Authentication > ESP Global Options.

  2. To activate an ESP global option, remove the # symbol before it, configure the value, save it, and then update the Access Gateway. By default, Access Manager displays seven options. You can configure any other options also, if required.

The following table lists the default ESP global options:

ESP Global Option

Description

forceESPSLOHTTP

Set true to enable the front channel logout for the Access Gateway initiated logout.

The default value is false.

For more information about how to enable front channel logout for the Access Gateway, see Defining Options for Liberty Identity Provider.

httponlyClusterCookie

Set false to disable the HTTPOnly flags for ESP cluster cookies.

The default value is true.

CLUSTER_COOKIE_DOMAIN

Set this property to change the Domain attribute for the ESP custer cookie in this format: CLUSTER_COOKIE_DOMAIN .example.com

CLUSTER_COOKIE_PATH

Set this property to change the Path attribute for the ESP custer cookie.

The default value is /nesp.

notifysessionTimetoIDP

Set false to disable sending session timeout message to the remote identity provider.

The default value is true.

For example, see Configuring the Liberty or SAML 2.0 Session Timeout.

RENAME_SESSIONID

Set false to prevent changing the Access Gateway session ID automatically.

The default value is true.

For example, see Preventing Automatically Changing Session ID in the Securing the Embedded Service Provider Session Cookie on the Access Gateway.

IS_DISPLAY_AUTH_DONE_PAGE

Set true to enable the Access Gateway to display post-authentication message.

The default value is false.

For example, see Enabling the Access Gateway to Display Post-Authentication Message.

NOTE:After you configure an ESP option, you cannot revert it to the previous configuration by clicking Revert in the Cluster Configuration page (Access Gateway > Edit > Revert).

3.8.3 Configuring Web Servers of a Proxy Service

The Web server configuration determines how the Access Gateway handles connections and packets between itself and the web servers.

IMPORTANT:For caching to work correctly, the Web servers must be configured to maintain a valid time. They must be configured to use an NTP server.

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

  2. Specify the hostname that is placed in the HTTP header of the packets being sent to the Web servers. In the Host Header field, select one of the following:

    • Forward Received Host Name: Indicates that you want the HTTP header to contain the published DNS name that the user sent in the request.

    • Web Server Host Name: Indicates that you want the published DNS name that the user sent in the request to be replaced by the DNS name of the Web server. Use the Web Server Host Name field to specify this name. You can also append the port number to the Web Server Host Name field. For example, <web server hostname>:<web server port number>.

  3. Select Error on DNS Mismatch to have the proxy determine whether the proxy service must compare the hostname in the DNS header that came from the browser with the DNS name specified in the Web Server Host Name option. The value in the parentheses is the value that comes in the header from the browser.

    If you enable this option and the names don't match, the request is not forwarded to the Web server. Instead, the proxy service returns an error to the requesting browser. This option is only available when you select to send the Web Server Host Name in the HTTP header.

    NOTE:The Error on DNS Mismatch option does not work in the following scenarios:

    • If the option is enabled in a protected resource.

    • If the option is enabled in a master host based service, and disabled in a path-based child services, then the Access Gateway does a strict check of DNS match for path-based child.

  4. If your browsers are capable of sending HTTP 1.1 requests, configure the following fields to match your Web servers:

    Enable Force HTTP 1.0 to Origin: Indicates whether HTTP 1.1 requests from browsers are translated to HTTP 1.0 requests before sending them to the Web server. If your browsers are sending HTTP 1.1 requests and your Web server can only handle HTTP 1.0 requests, you must enable this option.

    When the option is enabled, the Access Gateway translates an HTTP 1.1 request to an HTTP 1.0 request.

    Enable Session Stickiness: Selecting this option makes the proxy server to use the same Web server for all fills during a session.

  5. To enable SSL connections between the proxy service and its Web servers, select Connect Using SSL. For configuration information for this option, Web Server Trusted Root, and SSL Mutual Certificate, see Configuring SSL between the Proxy Service and the Web Servers.

  6. In the Connect Port field, specify the port that the Access Gateway must use to communicate with the Web servers. The following table lists some default port values for common types of Web servers.

    Server Type

    Non-Secure Port

    Secure Port

    Web server with HTML content

    80

    443

    WebSphere

    9080

    9443

    JBoss

    8080

    8443

  7. To control how idle and unresponsive Web server connections are handled and to optimize these processes for your network, select TCP Connect Options. For more information, see Configuring TCP Connect Options for Web Servers.

  8. To add a Web server, click New in the Web Server List and specify the IP address or the fully qualified DNS name of the Web server.

    The Web servers added to this list must contain identical Web content. Configuring your system with multiple servers with the same content adds fault tolerance and increases the speed for processing requests. For more information about this process, see Configuring Web Servers.

  9. To delete a Web server, select the Web server, then click Delete.

    This deletes the Web server from the list so that the Access Gateway no longer sends requests to the deleted Web server. At least one Web server must remain in the list. You must delete the proxy service to remove the last server in the list.

    NOTE:Do not remove all configured Web servers to the cluster if any of the cluster member does not have at least one Web server configured.

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

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

3.8.4 Configuring Protected Resources

A protected resource configuration specifies the directory (or directories) on the Web server that you want to protect. The protected resource configuration specifies the authorization procedures and the policies that must be used to enforce protection. The authentication procedures and the policies (Authorization, Identity Injection, and Form Fill) enable the single sign-on environment for the user. The type of protection a resource requires depends upon the resource, the Web server, and the conditions you define for the resource.

You can select from the following types of protection:

Authentication Procedures: Specifies the type of credentials the user must use to log in (such as name and password or secure name and password). You can select None for the procedure, which allows the resource to be a public resource, with no login required.

In addition to selecting the contract, you can also configure how the authentication procedure handles subsequent authentication requests from an application.

Authorization Policy: Specifies the conditions a user must meet to be allowed access to a protected resource. You define the conditions, and the Access Gateway enforces the Authorization policies. For example, you can assign roles to your users, and use these roles to grant and deny access to resources.

Identity Injection Policy: Specifies the information that must be injected into the HTTP header. If the Web application has been configured to look for certain fields in the header and the information cannot be found, the Web application determines whether the user is denied access or redirected. The Web application defines the requirements for Identity Injection. The Identity Injection policies allow you to inject the required information into the header.

Form Fill Policy: Allows you to manage forms that Web servers return in response to client requests. Form fill allows you to prepopulate fields in a form on first login and then securely save the information in the completed form to a secret store for subsequent logins. The user is prompted to reenter the information only when something changes, such as a password.

These policies allow you to design a custom access policy for each protected resource:

  • Resources that share the same protection requirements can be configured as a group. You set up the policies, and then add the URLs of each resource that requires these policies.

  • A resource that has specialized protection requirements can be set up as a single protected resource. For example, a page that uses Form Fill is usually set up as a single protected resource.

After configuring a protected resource, you can bookmark it. You cannot bookmark a login page that is used in a federation setup.

To configure a protected resource:

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Domain-Based Proxy Service or Primary Proxy Service] > Protected Resources.

    The Resource View of the Protected Resource List is used to create new protected resources or manage existing protected resources. The Policy View is used to see which policies are being used by multiple protected resources. For more information about the Policy View, see Assigning a Policy to Multiple Protected Resources.

  2. Select one of the following actions:

    New: To create a new protected resource, click this option and specify a display name for the resource. For configuration information, see Setting Up a Protected Resource.

    Delete: To delete a protected resource, select a protected resource, then click Delete.

    Enable: To enable a resource so that the Access Gateway protects it, select a protected resource, then click Enable.

    Disable: To disable protection for a resource, select a protected resource, then click Disable. After a resource is disabled, its path no longer has special protection. For example, you can set up a resource that allows access to all pages (for example /*) and another resource with special protection for a subpath. If you disable the subpath, make sure the security requirements of the /* resource are sufficient for the subpath.

    Also, when a protected resource is disabled, the resource no longer shows up in the Path List for a path-based multi-homing proxy.

  3. Select the name of a protected resource to perform the following tasks:

Setting Up a Protected Resource

  1. Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources.

  2. Either click the name of an existing resource or click New, then specify a display name for the resource.

  3. (Optional) Specify a description for the protected resource. You can use it to briefly describe the purpose for protecting this resource.

  4. Select the type of contract to use for the authentication procedure. The contract determines the information a user must supply for authentication. By default, the Administration Console allows you to select from the following contracts and options when specifying whether a resource requires an authentication contract:

    None: If you want to allow public access to the resource and not require an authentication contract, select None.

    Any Contract: If the user has authenticated, this option allows any contract defined for the Identity Server to be valid, or if the user has not authenticated, it prompts the user to authenticate, using the default contract assigned to the Identity Server configuration.

    Name/Password - Basic: Specifies basic authentication over HTTP, using a standard login pop-up provided by the Web browser.

    Name/Password - Form: Specifies a form-based authentication over HTTP or HTTPS, using the Access Manager login form.

    Secure Name/Password - Basic: Specifies basic authentication over HTTPS, using a standard login pop-up provided by the Web browser.

    Secure Name/Password - Form: Specifies a form-based authentication over HTTPS, using the Access Manager login form.

    The contract also determines the session timeout for inactive connections. If you have some resources that need to time out quickly to protect sensitive data and other resources that don’t need this kind of protection, you need to configure contracts for these resources. For more information about this feature, see Assigning a Timeout Per Protected Resource.

    If no contracts are available, you have not configured a relationship between the Access Gateway and the Identity Server. See Managing Reverse Proxies and Authentication.

  5. (Conditional) To modify how the authentication procedures are handled for a specific resource and contract, click the Edit Authentication Procedures icon.

    For configuration information, see Configuring an Authentication Procedure for Non-Redirected Login.

  6. Configure the URL Path.

    The default path is /*, which indicates everything on the Web server. Modify this if you need to restrict access to a specific directory on your Web server. If you have multiple directories on your Web server that require the same authentication contract and access control, add each directory as a URL path.

    New: To add a path, click New, specify the path, then click OK. For example, to allow access to all the pages in the public directory on the Web server, specify the following path:

    /public/*

    To allow access to all the files in a directory, but not to the subdirectories and their files, specify the following:

    /?
    /public/?

    The /? allows access to the root directory, but not the subdirectories. The /public/? allows access to the files in the public directory, but not the subdirectories.

    To allow access to files of a specific type, specify the following:

    /public/*.pdf

    This allows access to all the files in the public directory that have a PDF extension. Access to other file types and subdirectories is denied.

    To use this protected resource to protect a single page, specify the path and the filename. For example, to protect the login.html page in the /login directory, specify the following:

    /login/login.html

    This is the type of URL path you want to specify when you create a Form Fill policy for a protected resource. The URL Path List normally contains only this one entry. If you have multiple pages that the Form Fill policy applies to, list each one separately in the list. For optimum speed, you want the Access Gateway to be able to quickly identify the page and not search other pages to see if the policy applies to them.

    For more information about how a user’s request is matched to a protected resource, see Understanding URL Path Matching.

    For more information about using a query string, see Using a Query String in the URL Path.

    Modify: To modify a path, click the path link, then modify the URL Path.

    Delete: To delete a path, select the path, then click Delete.

  7. Click OK.

  8. In the Protected Resource List, ensure that the protected resource you created is enabled.

  9. (Optional) To add policies for protecting this resource, continue with one of the following:

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

Understanding URL Path Matching

The URL path determines which protected resource is used for a user request. Suppose you create one protected resource with the following URL paths:

/*
/test/*
/test/

You create a second protected resource with the following path:

/test/*.php

Users then send the following paths in their access requests:

/test/ 
/test/1/2/3/file.php
/file.php
/test/file.php
/test/file.php?param1=1234   

The first three requests (/test/, /test/1/2/3/file.php, and /file.php) match the first protected resource, and the last two requests (/test/file.php and /test/file.php?param1=1234) match the second protected resource.

You then add the following URL path to the first protected resource:

/test/?

This URL path in the first protected resource causes all the requests to match the first protected resource, and the second protected resource is ignored. The ? wildcard, which matches all content in the current directory, takes precedence over the more specific wildcard (*.php).

Using a Query String in the URL Path

You can specify a query string in the URL path of a protected resource. For example:

URL path: /test/index.html?test=test

When the requested URL has a query string, the Access Gateway searches for a protected resource with a matching URL path and query string. If it can’t find a match, the request returns a resource not found error.

The Access Gateway Service does not have this option. If you want the query string ignored, you must remove it from the URL path of the protected resource.

Configuring an Authentication Procedure for Non-Redirected Login

When a contract is created, it is assigned an authentication procedure that allows the user to be redirected to the Identity Server for authentication. Some applications, such as AJAX and WebDAV applications, do not support redirection for authentication. You can change the authentication behavior of a contract so that redirection does not occur.

When non-redirected login is enabled, the Access Gateway prompts the user to supply basic authentication credentials. The SOAP back channel between the Access Gateway and the Identity Server is used to complete the authentication on the user's behalf rather than a redirect. The SOAP back channel is also used for the session renewals.

Non-redirected login has the following restrictions:

  • Password Expiration Services: When you modify the authentication procedures to use non-redirected login, you cannot also use a password expiration service. Even when the Password expiration servlet and Allow user interaction options are configured, users are not redirected when their passwords are expiring and they are not prompted to change their passwords.

  • Locked Shared Secrets: When non-redirected login is enabled, users are not prompted for their passphrase for locked shared secrets.

  • Session Limits: Non-redirected login can cause the user to create more than one session with the Identity Server because the SOAP back channel uses a different process than authentication requests that are directed to the Identity Server. Therefore, do not limit your users to one session. Session limits are set by clicking Devices > Identity Servers > Edit.

If the contract you are going to use for non-redirected login is also assigned to protected resources that do not require non-redirected login, you must create a new authentication procedure for the resource requiring non-redirected login. Multiple authentication procedures can be configured to use the same contract.

To configure an authentication procedure:

  1. Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources > [Name of Protected Resource].

  2. On the Authentication Procedure line, click the Edit Authentication Procedure icon.

    The Authentication Procedure List displays all available contracts, the name of the authentication procedure they are assigned to, the protected resources that the authentication procedure has been assigned to, and whether the procedure has been enabled for non-redirected login.

  3. Select one of the following actions:

    • To create an new authentication procedure, click New, specify a name, then click OK. Continue with Step 4.

    • To modify an existing authentication procedure, click the name of the procedure. Continue with Step 4.

    • To delete an existing authentication procedure, select the procedure, then click Delete. Continue with Step 7.

      If the procedure is used by a resource, it cannot be deleted until it is not being used to protect resources. An authentication procedure must exist for each contract. If you delete an authentication procedure for a contract without also deleting the contract, the system automatically re-creates an authentication procedure for the contract.

  4. To specify the method for obtaining the credentials, fill in the following fields:

    Contract: Select the contract that you want to use for this protected resource. This needs to be a contract that supports basic authentication credentials such as Name/Password- Basic or Secure Name/Password-Basic. You can also configure Non-Redirected Login with a Kerberos contract.

    Non-Redirected Login: Select this option to use the SOAP back channel to verify the user’s credentials rather than a redirected request to the Identity Server.

    Realm: Specify a name that your users can use to identify the site that they are authenticating to. This could be your company name or the name of the application. The realm is displayed as a heading when the application requests a basic authentication.

    Redirect to Identity Server When No Authentication Header Is Provided: The response must provide an authentication header. If the first request does not contain the authentication header, you can select this option to allow the first request to be redirected to the Identity Server.

  5. Click OK.

  6. For the Authentication Procedure, select the authentication procedure you created or modified in Step 4.

  7. Click OK.

  8. Click Devices > Access Gateways, then update the Access Gateway.

  9. (Optional) For some configuration scenarios that use this feature, see

Assigning an Authorization Policy to a Protected Resource

An Authorization policy specifies conditions that a user must meet in order to access a resource. The Access Gateway enforces these conditions. The policy can specify the criteria a user must meet either to allow access or to deny access.

  1. Click Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Protected Resources > [Name of Protected Resource] > Authorization.

    The Authorization Policy List contains all the Access Gateway Authorization policies that have been created on this Administration Console for the selected policy container.

  2. Select one of the following:

    • To enable an existing policy, select the policy, then click Enable. Continue with Step 4.

    • To disable an existing policy, select the policy, then click Disable. Continue with Step 4.

    • To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected resources. If you modify the policy, you are also affecting how this policy protects those resources. For configuration information, see Authorization Policies.

      When you have completed your policy modifications, continue with Step 4.

    • To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select Access Gateway: Authorization as the type, then click OK. For configuration information, see Creating Access Gateway Authorization Policies.

      When you have created your policy, continue with Step 3.

  3. To enable the policy you just created, select the policy, then click Enable.

    Only the policies that are enabled are applied to this resource. All available Authorization policies are listed. If you use the same policy for multiple protected resources, use the policy description field to indicate this.

  4. To save your changes to the browser cache, click OK.

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

Assigning an Identity Injection Policy to a Protected Resource

The Web application defines the requirements for Identity Injection. If a Web application has been configured to look for certain fields in the header and the information cannot be found, the Web application determines whether the user is denied access, granted access, or redirected. You configure an Identity Injection policy to inject into the HTTP header the information that the Web application requires.

  1. Click Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected Resources > [Name of Protected Resource] > Identity Injection.

    The Identity Injection Policy List contains all the Identity Injection policies that have been created on this Administration Console for the selected policy container.

  2. Select one of the following:

    • To enable an existing policy, select the policy, then click Enable. Only the policies that are enabled are applied to this resource. Continue with Step 4.

    • To disable an existing policy, select the policy, then click Disable. Continue with Step 4.

    • To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected resources. If you modify the policy, you are also affecting how this policy protects those resources. For configuration information, see Section 6.4, Identity Injection Policies.

      When you have finished your policy modifications, continue with Step 4.

    • To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select Access Gateway: Identity Injection as the type, then click OK. For configuration information, see Section 6.4, Identity Injection Policies.

      When you have created your policy, continue with Step 3.

  3. To enable the policy you just created, select the policy, then click Enable.

    Only the policies that are enabled are applied to this resource. If you use the same policy for multiple protected resources, use the policy description field to indicate this.

  4. To save your changes to the browser cache, click OK.

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

IMPORTANT:If you enable an Identity Injection policy for a protected resource that has been assigned to use a contract that does not prompt the user for a password and the Identity Injection policy injects the user’s password, single sign-on cannot be enabled because the password is not available. However, you can create a contract that retrieves the user’s password when the user is not prompted for a password when authenticating. See Password Retrieval.

Assigning a Form Fill Policy to a Protected Resource

Some client requests cause the Web server to return a form. Sometimes this form contains a request to log in. If you create a Form Fill policy, you can have the Access Gateway fill in the form. When a user first logs in, the Access Gateway prepopulates some fields and prompts the users for the others. The Access Gateway securely saves the information, so that on subsequent logins, the Access Gateway can fill in the form. The user is only prompted to fill in the form when something changes, such as a password expiring.

Form Fill uses two components: the HTML form and the Form Fill policy. The HTML form is created with HTML tags and consists of form elements such as fields, menus, check boxes, and buttons. The Form Fill policy is created by specifying the following:

  • Which information is entered automatically and not displayed to the user.

  • Which information is displayed so that the user, at least the first time, can enter the information.

  • What is done with the information (for example, whether it is saved so that the user does not need to enter it when accessing the form again).

You must create the policy before you can assign it to a resource (see Section 6.5, Form Fill Policies). To assign a Form Fill policy to a protected resource:

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected Resources > [Name of Protected Resource].

  2. Examine the entries in the URL Path List.

    Ideally, the URL to which you are assigning a Form Fill policy must be a single HTML page or a few HTML pages. If possible, it must not be a URL that ends in a wildcard (for example, an asterisk) and therefore matches many pages.

    IMPORTANT:When the URL ends in a wildcard, the Access Gateway must search each page that matches the URL and check to see if it contains the form. This adds extra processing overhead for all the pages that match the URL, but do not contain the form. For more information about the performance problems this can cause, see Section 6.5, Form Fill Policies.

  3. (Conditional) If the URL is not specific, click the name of the path and modify it.

  4. Click Form Fill.

    The Form Fill Policy List contains all the Form Fill policies that have been created on this Administration Console for the selected policy container.

  5. Select one of the following:

    • To enable an existing policy, select the policy, then click Enable. Only the policies that are enabled are applied to this resource. Continue with Step 7.

    • To disable an existing policy, select the policy, then click Disable. Continue with Step 7.

    • To edit an existing policy, click the name of the policy. Remember that policies can be assigned to multiple protected resources. If you modify the policy, you are also affecting how this policy protects those resources. For configuration information, see Section 6.5, Form Fill Policies.

      When you have finished the policy modifications, continue with Step 7.

    • To create a new policy, click Manage Policies. On the Policies page, click New, specify a display name, select Access Gateway: Form Fill as the type, then click OK. For configuration information, see Section 6.5, Form Fill Policies.

      When you have created your new policy, continue with Step 6.

  6. To enable the policy you just created, select the policy, then click Enable.

    Only the policies that are enabled are applied to this resource. If you use the same policy for multiple protected resources, use the policy description field to indicate this.

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

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

IMPORTANT:If you enable a Form Fill policy for a protected resource that has been assigned to use a contract that does not prompt the user for a password and the Form Fill policy contains a field for the user’s password, single sign-on cannot be enabled because the password is not available. To enable single sign-on, you need to use an Authentication class that retrieves the user’s password and injects it into the user’s credentials when the user authenticates using a non-password method such as X.509, RADIUS, smart card, or Kerberos. For information about such a class, see Password Retrieval.

Assigning a Timeout Per Protected Resource

If all your resources are using the same contract and you want them all to have the same timeout for inactivity, you set the Authentication Timeout option on the contract to the required limit and leave the Activity Realm option blank. The user logs in, and activity by the user on any resource keeps the user’s session active. The user is prompted to reauthenticate only when the user has no activity on any resources for longer than the authentication timeout value.

If you have some resources that require a shorter timeout than other resources, you need to balance the need for single sign-on with the timeout requirements:

  • To strictly enforce a timeout, the resource needs to be assigned to a custom contract.

  • To preserve single sign-on, resources need to be assigned to the same contract.

The protected resource is assigned to use a contract, and the timeout is assigned to the contract. For information about how to configure the contract, see Configuring Authentication Contracts.

The following sections describe four configuration scenarios and the user experience that they create.

Scenario 1: If strictly adhering to the timeout value is more important than preserving the session or single sign-on, configure your resources as follows:

  • Protected resource 1 (PR1) is configured to use contract 1 (C1), which has been created from method 1 (M1) and placed in its own activity realm (AR1). For this scenario you set the authentication timeout to 30 minutes.

  • Protected resource 2 (PR2) is configured to use contract 2 (C2), which has been created from method 2 (M2) and placed in its own activity realm (AR2). For this scenario, you set the authentication timeout to 15 minutes.

With this scenario, the user is prompted to log in when accessing PR1 and when accessing PR2. Each resource has its own time line, because each resource belongs to its own activity realm. Figure 3-5 The figure below illustrates this scenario.

Figure 3-5 Login Requirements with Separate Methods and Separate Activity Realms

After authenticating to both resources and remaining active on both resources for the first 10 minutes, the sessions remain active. The user then stays active on PR1 without accessing PR2 for over 15 minutes. The AR1 time line is updated with this activity. The AR2 time line is not updated. When the user accesses PR2 after more than 15 minutes of inactivity on the AR2 time line, the user is prompted to authenticate. The user then returns to PR1 after over 20 minutes of inactivity, but AR1 time line shows activity within the 30-minute timeout. The user is granted access and does not need to log in again to access PR1.

In this scenario, the resources are independent of each other and do not influence each other’s timeout limits.

Scenario 2: If you are willing to allow a resource to influence the timeout of another resource, configure your resources as follows:

  • Protected resource 1 (PR1) is configured to use contract 1 (C1), which has been created from method 1 (M1) and placed in a shared activity realm (shared1). For this scenario you set the authentication timeout to 30 minutes.

  • Protected resource 2 (PR2) is configured to use contract 2 (C2), which has been created from method 2 (M2) and placed in a shared activity realm (shared1). For this scenario, you set the authentication timeout to 15 minutes.

With this scenario, the user is prompted to log in when accessing PR1 and when accessing PR2. Activity at either resource updates the shared1 time line. Figure 3-6 illustrates this scenario.

Figure 3-6 Login Requirements for Separate Methods with a Shared Activity Realm

As long as the user is active on PR1, the user’s session to PR2 remains active. After 20 minutes of activity on PR1, the user returns to PR2. The user is allowed access and does not need to log in because the shared1 time line shows activity within the last 5 minutes. The user remains active on PR2 for over 30 minutes, then accesses PR1. Again, the shared1 time line shows activity within the last 5 minutes, so the user is granted access to PR1 without logging in again.

With this configuration, activity at other resources influences the time limits so that they are not strictly enforced.

Scenario 3: If single sign-on is more important than strictly enforcing a timeout value, NetIQ recommends that you configure all contracts to have the same authentication timeout value.

If you configure your resources as follows, you might not get the behavior you require:

  • Protected resource 1 (PR1) is configured to use contract 1 (C1), which has been created from method 1 (M1) and placed in a shared activity realm (shared1). For this scenario you set the authentication timeout to 30 minutes.

  • Protected resource 2 (PR2) is configured to use contract 2 (C2), which has been created from method 1 (M1) and placed in a shared activity realm (shared1). For this scenario, you set the authentication timeout to 15 minutes.

Because C1 and C2 are created from the same method (M1), the user does not need to log in twice to access both resources. Logging in to one resource allows them access to the other resource. Figure 3-7 illustrates this scenario.

Figure 3-7 Login Requirements for Shared Methods and Shared Realms

The user first logs in to PR2 and is active for 10 minutes. The shared1 time line gets updated with this activity. When the user requests access to PR1, the user is granted access without being prompted for credentials. The user is then active on PR1 for over 20 minutes. When the user requests access to PR2, even though the user has been inactive on this resource for over 20 minutes, the user is granted access because the time line shows activity within the last five minutes.

With this configuration, PR2 does not time out as long as the user remains active on PR1. However, when the user goes inactive on both PR2 and PR1 for over 15 minutes and the user requests access to PR1, the time line shows no activity within the time limit specified for PR2 and the user is prompted to log in.

Scenario 4: NetIQ does not recommend that you set different authentication timeouts on contracts and then use the Any contract option for protected resources. If you want to use the Any contract, then you must set the authentication timeout to the same value on all contracts. If the timeouts are not the same, you cannot consistently predict what timeouts are being applied to the various protected resources. For example, the user requests access to a resource that is protected with a contract with a short timeout. The user logs in, then accesses resources that use the Any contract option. All of these resources are assigned a short timeout.The user then goes inactive and the session times out. The user then requests access to a resource with a contract with a long timeout. The user logs in, and after a few minutes, accesses same resources protected with the Any contract option. These resources are now assigned the long timeout value.

Assigning a Policy to Multiple Protected Resources

If you have created multiple protected resources that need to be protected by the same policy or policies, you can use the policy view to assign a policy to multiple protected resources. However, the protected resources must belong to the same proxy service.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Reverse Proxy Name] > [Name of Proxy Service] > Protected Resources.

  2. Select the Policy View.

  3. Select the Used By link of the policy you want to assign to multiple resources.

    The Policy and Policy Container fields identify the policy. The Protected Resource Policy Usage List displays the protected resources defined for this proxy service and indicates which resources the policy has been enabled on.

  4. To enable the policy for multiple resources, either select them one by one or click Name to select all of them, then click Enable. To disable a policy for a resource, select the resource, then click Disable.

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

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

3.8.5 Configuring HTML Rewriting

Access Gateway configurations generally require HTML rewriting because the Web servers are not aware that the Access Gateway machine is obfuscating their DNS names. URLs contained in their pages must be checked to ensure that these references contain the DNS names that the client browser understands. On the other end, the client browsers are not aware that the Access Gateway is obfuscating the DNS names of the resources they are accessing.

The URL requests coming from the client browsers that use published DNS names must be rewritten to the DNS names that the Web servers expect. Figure 3-8 illustrates these processes.

Figure 3-8 HTML Rewriting

The following sections describe the HTML rewriting process:

Understanding the Rewriting Process

The Access Gateway needs to rewrite URL references under the following conditions:

  • To ensure that URL references contain the proper scheme (HTTP or HTTPS).

    If your Web servers and Access Gateway machines are behind a secure firewall, you might not require SSL sessions between them, and only require SSL between the client browser and the Access Gateway. For example, an HTML file being accessed through the Access Gateway for the Web site novell.com might have a URL reference to http://novell.com/path/image1.jpg. If the reverse proxy for novell.com/path is using SSL sessions between the browser and Access Gateway, the URL reference http://novell.com/path/image1.jpg must be rewritten to https://novell.com/path/image1.jpg. Otherwise, when the user clicks the HTTP link, the browser must change from HTTP to HTTPS and establish a new SSL session.

  • To ensure that URL references containing private IP addresses or private DNS names are changed to the published DNS name of the Access Gateway or hosts.

    For example, suppose that a company has an internal Web site named data.com, and wants to expose this site to Internet users through the Access Gateway by using a published DNS name of novell.com. Many of the HTML pages on this Web site have URL references that contain the private DNS name, such as http://data.com/imagel.jpg. Because Internet users are unable to resolve data.com/imagel.jpg, links using this URL reference would return DNS errors in the browser.

    The HTML rewriter can resolve this issue. The DNS name field in the Access Gateway configuration is set to novell.com, which users can resolve through a public DNS server to the Access Gateway. The rewriter parses the Web page, and any URL references matching the private DNS name or private IP address listed in the Web server address field of the Access Gateway configuration are rewritten to the published DNS name novell.com and the port number of the Access Gateway.

    Rewriting URL references addresses two issues: 1) URL references that are unreachable because of the use of private DNS names or IP addresses are now made accessible and 2) Rewriting prevents the exposure of private IP addresses and DNS names that might be sensitive information.

  • To ensure that the Host header in incoming HTTP packets contains the name understood by the internal Web server.

    Using the example in Figure 3-8, suppose that the internal Web server expects all HTTP or HTTPS requests to have the Host field set to data.com. When users send requests using the published DNS name novell.com/path, the Host field of the packets in those requests received by the Access Gateway is set to novell.com. The Access Gateway can be configured to rewrite this public name to the private name expected by the Web server by setting the Web Server Host Name option to data.com. Before the Access Gateway forwards packets to the Web server, the Host field is changed (rewritten) from novell.com to data.com. For information about configuring this option, see Configuring Web Servers of a Proxy Service.

The rewriter searches for URLs in the following HTML contexts. They must meet the following criteria to be rewritten:

Context

Criteria

HTTP Headers

Qualified URL references occurring within certain types of HTTP response headers such as Location and Content-Location are rewritten. The Location header is used to redirect the browser to where the resource can be found. The Content-Location header is used to provide an alternate location where the resource can be found.

JavaScript

Within JavaScript, absolute references are always evaluated for rewriting. Relative references (such as index.html) are not attempted. Absolute paths (such as /docs/file.html) are evaluated if the page is read from a path-based multi-homing Web server and the reference follows an HTML tag. For example, the string href='/docs/file.html' is rewritten if /docs is a multi-homing path that has been configured to be removed.

HTML Tags

URL references occurring within the following HTML tag attributes are evaluated for rewriting:

action                  archive             background
cite                    code                codebase
data                    dynscr              filterLink
href                    longdesc            lowsrc
o:WebQuerySourceHref    onclick             onmenuclick
pluginspage             src                 usemap
usermapborderimage

References

An absolute reference is a reference that has all the information needed to locate a resource, including the hostname, such as http://internal.web.site.com/index.html. The rewriter always attempts to rewrite absolute references.

The rewriter attempts to rewrite an absolute path when it is the multi-homing path of a path-based multi-homing service. For example, /docs/file1.html is rewritten if /docs is a multi-homing path that has been configured to be removed.

Relative references are not rewritten.

Query Strings

URL references contained within query strings can be configured for rewriting by enabling the Rewrite Inbound Query String Data option.

Post Data

URL references specified in Post Data can be configured for rewriting by enabling the Rewrite Inbound Post Data option.

Specifying DNS Names to Rewrite

The rewriter parses and searches the Web content that passes through the Access Gateway for URL references that qualify to be rewritten. URL references are rewritten when they meet the following conditions:

  • URL references containing DNS names or IP addresses matching those in the Web server address list are rewritten with the Published DNS Name.

  • URL references matching the Web Server Host Name are rewritten with the Published DNS Name.

  • URL references matching entries in the Additional DNS Name List of the host are rewritten with the Published DNS Name. The Web Server Host Name does not need to be included in this list.

  • The DNS names in the Exclude DNS Name List specify the names that the rewriter must skip and not rewrite.

NOTE:Excludes in the Exclude DNS Name List are processed first, then the includes in the Additional DNS Name List. If you put the same DNS name in both lists, the DNS name is rewritten.

The following sections describe the conditions to consider when adding DNS names to the lists:

Determining Whether You Need to Specify Additional DNS Names

Sometimes Web pages contain URL references to a hostname that does not meet the default criteria for being rewritten. That is, the URL reference does not match the Web Server Host Name or any value (IP address) in the Web Server List. If these names are sent back to the client, they are not resolvable. Figure 3-9 illustrates a scenario that requires an entry in the Additional DNS Name List.

Figure 3-9 Rewriting a URLs for Web Servers

The page on the data.com Web server contains two links, one to an image on the data.com server and one to an image on the graphics.com server. The link to the data.com server is automatically rewritten to novell.com, when rewriting is enabled. The link to the image on graphics.com is not rewritten, until you add this URL to the Additional DNS Name List. When the link is rewritten, the browser knows how to request it, and the Access Gateway knows how to resolve it.

You need to include names in this list if your Web servers have the following configurations:

  • If you have a cluster of Web servers that are not sharing the same DNS name, you need to add their DNS names to this list.

  • If your Web server obtains content from another Web server, the DNS name for this additional Web server needs to be added to the list.

  • If the Web server listens on one port (for example, 80), and redirects the request to a secure port (for example, 443), the DNS name needs to be added to the list. The response to the user comes back on https://<DNS_name>:443. This does not match the request that was sent on http://<DNS_name>:80. If you add the DNS name to the list, the response can be sent in the format that the user expects.

  • If an application is written to use a private hostname, you need to add the private hostname to the list. For example, assume that an application URL reference contains the hostname of home (http://home/index.html). This hostname needs to be added to the Additional DNS Name List.

  • If you enable the Forward Received Host Name option on your path-based multi-homing service and your Web server is configured to use a different port, you need to add the DNS name with the port to the Additional DNS Name List.

    For example, if the public DNS name of the proxy service is www.myag.com, the path for the path-based multi-homing service is /sales, and the Web server port is 801, the following DNS name needs to be added to the Additional DNS Name List of the /sales service:

    http://www.myag.com:801

When you enter a name in the list, it can use any of the following formats:

DNS_name
host_name
IP_address
scheme://DNS_name
scheme://IP_address
scheme://DNS_name:port
scheme://IP_address:port

For example:

HOME
https://www.backend.com
https://10.10.15.206:444

These entries are not case sensitive.

Determining Whether You Need to Exclude DNS Names from Being Rewritten

If you have two reverse proxies protecting the same Web server, the rewriter correctly rewrites the references to the Web server so that browser always uses the same reverse proxy. In other words, if the browser requests a resource using novell.com.uk, the response is returned with references to novell.com.uk and not novell.com.usa.

If you have a third reverse proxy protecting a Web server, the rewriting rules can become ambiguous. For example, consider the configuration illustrated in Figure 3-10.

Figure 3-10 Excluding URLs

A user accesses data.com through the published DNS name of novell.com.mx. The data.com server has references to product.com. The novell.com.mx proxy has two ways to get to the product.com server because this Web server has two published DNS names (novell.com.uk and novell.com.usa). The rewriter could use either of these names to rewrite references to product.com.

  • If you want all users coming through novell.com.mx to use the novell.com.usa proxy, you need to block the rewriting of product.com to novell.com.uk. On the HTML Rewriting page of the reverse proxy for novell.com.uk, add product.com and any aliases to the Exclude DNS Name List.

  • If you do not care which proxy is returned in the reference, you do not need to add anything to the Exclude DNS Names List.

Defining the Requirements for the Rewriter Profile

An HTML rewriter profile allows you to customize the rewriting process and specify the profile that is selected to rewrite content on a page. This section describes the following features of the rewriter profile:

Types of Rewriter Profiles

The Access Gateway has the following types of profiles:

Default Word Profile

The default Word profile, named default, is not specific to a reverse proxy or its proxy services.

If you enable HTML rewriting, but you do not define a custom Word profile for the proxy service, the default Word profile is used. This profile is preconfigured to rewrite the Web Server Host Name and any other names listed in the Additional DNS Name List. The preconfigured profile matches all URLs with the following content-types:

text/html

text/javascript

text/xml

application/javascript

text/css

application/x-javascript

When you modify the behavior of the default profile, remember its scope. If the default profile does not match your requirements, you must usually create your own custom Word profile or custom Character profile.

Custom Word Profile

A Word profile searches for matches on words. For example, “get” matches the word “get” and any word that begins with “get” such as “getaway” but it does not match the “get” in “together” or “beget.”

For information about how strings are replaced in a Word profile, see the following:

You must create a custom Word profile when an application requires rewrites of paths in JavaScript. If the application needs strings replaced or new content-types, these can also be added to the custom profile. In a custom Word profile, you can also configure the match criteria so that the profile matches specific URLs. For more information, see Page Matching Criteria for Rewriter Profiles.

When you create a custom Word profile, you need to position it before the default profile in the list of profiles. Only one Word profile is applied per page. The first Word profile that matches the page is applied. Profiles lower in the list are ignored.

Custom Character Profile

A custom Character profile searches for matches on a specified set of characters. For example, “top” matches the word “top” and the “top” in “tabletop,” “stopwatch,” and “topic.” If you need to replace strings that require this type of search, you must create a custom Character profile.

For information about how strings are replaced in a Character profile, see String Replacement Rules for Character Profiles.

In a custom Character profile, you can also configure the match criteria so that the profile matches specific URLs. For more information, see Page Matching Criteria for Rewriter Profiles.

After the rewriter finds and applies the Word profile that matches the page, it finds and applies one Character profile. The first Character profile that matches the page is applied. Character profiles lower in the list are ignored.

Page Matching Criteria for Rewriter Profiles

You specify the following matching criteria for selecting the profile:

  • The URLs to match

  • The URLs that cannot match

  • The content types to match

You use the Requested URLs to Search section of the profile to set up the matching policy. The first Word profile and the first Character profile that matches the page is applied. Profiles lower in the list are ignored.

URLs: The URLs specified in the policy must use the following formats:

Sample URL

Description

http://www.a.com/content

Matches pages only if the requested URL does not contain a trailing slash.

http://www.a.com/content/

Matches pages only if the requested URL does contain a trailing slash.

http://www.a.com/content/index.html

Matches only this specific file.

http://www.a.com/content/*

Matches the requested URL whether or not it has a trailing slash and matches all files in the directory.

http://www.a.com/*

Matches the proxy service and everything it is protecting.

You can specify two types of URLs. In the If Requested URL Is list, you specify the URLs of the pages you want this profile to match. In the And Requested URL Is Not list, you specify the URLs you don’t want this profile to match. You can use the asterisk wildcard for a URL in the If Requested URL Is list to match pages you really don’t want this profile to match, then use a URL in the And Requested URL Is Not list to exclude them from matching. If a page matches both a URL in the If Requested URL Is list and in the And Requested URL Is Not list, the profile does not match the page.

For example, you could specify the following URL in the If Requested URL Is list:

http://www.a.com/*

You could then specify the following URL in the And Requested URL Is Not list:

http://www.a.com/content/*

These two entries cause the profile to match all pages on the www.a.com Web server except for the pages in the /content directory and its subdirectories.

IMPORTANT:If nothing is specified in either of the two lists, the profile skips the URL matching requirements and uses the content-type to determine if a page matches.

Content-Type: In the And Document Content-Type Is section, you specify the content-types you want this profile to match. To add a new content-type, click New and specify the name, such as text/dns. Search your Web pages for content-types to determine if you need to add new types. To add multiple values, enter each value on a separate line.

Regardless of content-types you specify, the page matches the profile if the file extension is html, htm, shtml, jhtml, asp, or jsp and you have not specified any URL matching criteria.

Possible Actions for Rewriter Profiles

The rewriter action section of the profile determines the actions the rewriter performs when a page matches the profile. Select from the following:

Inbound Actions: A profile might require these options if the proxy service has the following characteristics:

  • URLs appear in query strings, Post Data, or headers.

  • The Web server uses WebDAV methods.

If your profile needs to match pages from this type of proxy service, you might need to enable the options listed below. They control the rewriting of query strings, Post Data, and headers from the Access Gateway to the Web server.

  • Rewrite Inbound Query String Data: Select this option to rewrite the domain and URL in the query string to match the Web server configuration or to remove the path from the query string on a path-based multi-homing proxy with the Remove Path on Fill option enabled.

  • Rewrite Inbound Post Data: Select this option to rewrite the domain and URL in the Post Data to match the Web server configuration or to remove the path from the Post Data on a path-based multi-homing proxy with the Remove Path on Fill option enabled.

  • Rewrite Inbound Headers: Select this option to rewrite the following headers:

    • Call-Back
    • Destination
    • If
    • Notification-Type
    • Referer

The inbound options are not available for a Character profile.

Enabling or Disabling Rewriting: The Enable Rewriter Actions option determines whether the rewriter performs any actions:

  • Select the option to have the rewriter rewrite the references and data on the page.

  • Leave the option deselected to disable rewriting. This allows you to create a profile for the pages you do not want rewritten.

Additional Names to Search for URL Strings to Rewrite with Host Name: Use this section to specify the name of the variable, attribute, or method in which the hostname might appear. These options are not available for a Character profile.

  • Variable and Attribute Name to Search for Is: Use this section to specify the HTML attributes or JavaScript variables that you want searched for DNS names that might need to be rewritten. For the list of HTML attribute names that are automatically searched, see HTML Tags. You might want to add the following attributes:

    • value: This attribute enables the rewriter to search the <param> elements on the HTML page for value attributes and rewrite the value attributes that are URL strings.

      If you need more granular control (some need to be rewritten but others do not) and you can modify the page, see Disabling with Page Modifications.

    • formvalue: This attribute enables the rewriter to search the <form> element on the HTML page for <input>, <button>, and <option> elements and rewrite the value attributes that are URL strings. For example, if your multi-homing path is /test and the form line is <input name="navUrl" type="hidden" value="/IDM/portal/cn/GuestContainerPage/656gwmail">, this line would be rewritten to the following value before sending the response to the client:

      <input name="navUrl" type="hidden" value="/test/IDM/portal/cn/GuestContainerPage/656gwmail">

      The formvalue attribute enables the rewriting of all URLs in the <input>, <button>, and <option> elements in the form.If you need more granular control (some need to be rewritten but others do not) and you can modify the form page, see Disabling with Page Modifications.

  • Replacing URLs in Java Methods: The JavaScript Method to Search for Is list allows you to specify the Java methods to search to see if their parameters contain a URL string.

String Replacement: The Additional Strings to Replace list allows you to search for a string and replace it. The search boundary (word or character) that you specified when creating the profile is used when searching for the string.

Word profile search and replace actions take precedence over character profile actions.

For the rules and tokens that can be used in the search strings, see the following:

For information about how the Additional Strings to Replace list can be used to reduce the number of Java methods you need to list, see Using $path to Rewrite Paths in JavaScript Methods or Variables.

String Replacement Rules for Word Profiles

In a Word profile, a string matches all paths that start with the characters in the specified string. For example:

Search String

Matches This String

Does not’ Match This String

/path

/path

/pathother

/path/other

/path.html

/mypath

String Tokens

On the Access Gateway Service, you can use the following special tokens to modify the default matching rules.

  • [w] to match one white space character

  • [ow] to match 0 or more white space characters

  • [ep] to match a path element in a URL path, excluding words that end in a period

  • [ew] to match a word element in a URL path, including words that end in a period

  • [oa] to match one or more alphanumeric characters

White Space Tokens: You use the [w] and the [ow] tokens to specify where white space might occur in the string. For example:

[ow]my[w]string[w]to[w]replace[ow]

If you don’t know, or don’t care, whether the string has zero or more white characters at the beginning and at the end, use [ow] to specify this. The [w] specifies exactly one white character.

Path Tokens: You use the [ep] and [ew] tokens to match path strings. The [ep] token can be used to match the following types of paths:

Search String

Matches This String

Does not’ Match This String

/path[ep]

/path

/home/path/other

/path.html

/home/pathother

The [ew] token can be used to match the following types of paths:

Search String

Matches This String

Does not Match This String

/path[ew]

/path.html

/home/path

/paths

Name Tokens: You use the [oa] token to match function or parameter names that have a set string to start the name and end the name, but the middle part of the name is a computer-generated alphanumeric string. For example, the [oa] token can be used to match the following types of names:

Search String

Matches This String

Does not’ Match This String

javaFunction-[oa](

javaFunction-1234a56()

javaFunction-a()

javaFunction()

String Replacement Rules for Character Profiles

When you configure multiple strings for replacement, the rewriter uses the following rules for determining how characters are replaced in strings:

  • String replacement is done as a single pass.

  • String replacement is not performed recursively. Suppose you have listed the following search and replacement strings:

    DOG     to be replaced with     CAT
    A       to be replaced with     O

    All occurrences of the string DOG are replaced with CAT, regardless of whether it is the word DOG or the word DOGMA. Only one replacement pass occurs. The rewritten CAT is not replaced with COT.

  • Because string replacement is done in one pass, the string that matches first takes precedence. Suppose you have listed the following search and replacement strings:

    ABC       to be replaced with     XYZ
    BCDEF     to be replaced with     PQRSTUVWXYZ

    If the original string is ABCDEFGH, the replaced string is XYZDEFGH.

  • If two specified search strings match the data portion, the search string of longer length is used for the replacement except for the case detailed above. Suppose you have listed the following search and replacement strings:

    ABC        to be replaced with     XYZ
    ABCDEF     to be replaced with     PQRSTUVWXYZ

    If the original string is ABCDEFGH, the replaced string is PQRSTUVWXYZGH.

Using $path to Rewrite Paths in JavaScript Methods or Variables

You can use the $path token to rewrite paths on a path-based multi-homing service that has the Remove Path on Fill option enabled. This token is useful for Web applications that require a dedicated Web server and are therefore installed in the root directory of the Web server. If you protect this type of application with Access Manager using a path-based multi-homing service, your clients access the application with a URL that contains a /path value. The proxy service uses the path to determine which Web server a request is sent to, and the path must be removed from the URL before sending the request to the Web server.

The application responds to the requests. If it uses JavaScript methods or variables to generate paths to resources, these paths are sent to client without prepending the path for the proxy service. When the client tries to access the resource specified by the Web server path, the proxy service cannot locate the resource because the multi-homing path is missing. The figure below illustrates this flow with the rewriter adding the multi-homing path in the reply.

Figure 3-11 Rewriting with a Multi-homing Path

To make sure all the paths generated by JavaScript are rewritten, you must search the Web pages of the application. You can then either list all the JavaScript methods and variables in the Additional Names to Search for URL Strings to Rewrite with Host Name section of the rewriter profile, or you can use the $path token in the Additional Strings to Replace section. The $path token reduces the number of JavaScript methods and variables that you otherwise need to list individually.

To use the $path token, you add a search string and a replace string that uses the token. For example, if the /prices/pricelist.html page is generated by JavaScript and the multi-homing path for the proxy service is /inner, you would specify the following stings:

Search String

Replacement String

/prices

$path/prices

This configuration allows the following paths to be rewritten before the Web server sends the information to the browser.

Web Server String

Rewritten String for the Browser

/prices/pricelist.html

/inner/prices/pricelist.html

/prices

/inner/prices

This token can cause strings that shouldn’t be changed to be rewritten. If you enable the Rewrite Inbound Query String Data, Rewrite Inbound Post Data, and Rewrite Inbound Header actions, the rewriter checks these strings and ensures that they contain the information the Web server expects. For example, when these options are enabled, the following paths and domain names are rewritten when found in query strings, in Post Data, or in the Call-Back, Destination, If, Notification-Type, or Referer headers.

Browser String

Rewritten String for the Web Server

/inner/prices/pricelist.html

/prices/pricelist.html

/inner/prices

/prices

novell.com/inner/prices

inner.com/prices

Configuring the HTML Rewriter and Profile

You configure the HTML rewriter for a proxy service, and these values are applied to all Web servers that are protected by this proxy service.

To configure the HTML rewriter:

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

    The HTML Rewriting page specifies which DNS names are to be rewritten. The HTML Rewriter Profile specifies which pages to search for DNS names that need to be rewritten.

  2. Select Enable HTML Rewriting.

    This option is enabled by default. When it is disabled, no rewriting occurs.When enabled, this option activates the internal HTML rewriter. This rewriter replaces the name of the Web server with the published DNS name when sending data to the browsers. It replaces the published DNS name with the Web Server Host Name when sending data to the Web server. It also makes sure the proper scheme (HTTP or HTTPS) is included in the URL. This is needed because you can configure the Access Gateway to use HTTPS between itself and client browsers and to use HTTP between itself and the Web servers.

  3. In the Additional DNS Name List section, click New, specify a DNS that appears on the Web pages of your server (for example a DNS name other than the Web server’s DNS name), then click OK.

    For more information, see Determining Whether You Need to Specify Additional DNS Names.

  4. In the Exclude DNS Name List section, click New, specify a DNS name that appears on the Web pages of your server that you do not want rewritten, then click OK.

    For more information, see Determining Whether You Need to Exclude DNS Names from Being Rewritten.

  5. Use the HTML Rewriter Profile List to configure a profile. Select one of the following actions:

    • New: To create a profile, click New. Specify a display name for the profile and select either a Word or Character for the Search Boundary. Continue with Creating or Modifying a Rewriter Profile.

      • Word: A Word profile searches for matches on words. For example, “get” matches the word “get” and any word that begins with “get” such as “getaway” but it does not match the “get” in “together” or “beget.”

        If you create multiple Word profiles, order is important. The first Word profile that matches the page is applied. Word profiles lower in the list are ignored.

      • Character: A Character profile searches for matches on a specified set of characters. For example, “top” matches the word “top” and the “top” in “tabletop,” “stopwatch,” and “topic.”

        If you want to add functionality to the default profile, create a Character profile. It has all the functionality of a Word profile, except searching for attribute names and Java variables and methods. If you create multiple Character profiles, order is important. The first Character profile that matches the page is applied. Character profiles lower in the list are ignored.

    • Delete: To delete a profile, select the profile, then click Delete.

    • Enable: To enable a profile, select the profile, then click Enable.

    • Disable: To disable a profile, select the profile, then click Disable.

    • Modify: To view or modify the current configuration for a profile, click the name of the profile. Continue with Creating or Modifying a Rewriter Profile.

      The default profile is designed to be applied to all pages protected by the Access Gateway. It is not specific to a reverse proxy or its proxy services. If you modify its behavior, remember its scope. Rather than modify the default profile, you must create your own custom Word profile and enable it.

  6. If you have more than one profile in the HTML Rewriter Profile List, use the up-arrow and down-arrow buttons to order the profiles.

    If you create more than one profile, order becomes important. For example if you want to rewrite all pages with a general rewriter profile (with a URL such as /*) and one specific set of pages with another rewriter profile (with a URL such as /doc/100506/*), you need to have the specific rewriter profile listed before the general rewriter profile.

    Even if multiple Word or Character profiles are enabled, a maximum of one Word profile and one Character profile is executed per page. The first Word profile and Character profile in the list that matches a page are executed, and the others are ignored.

  7. Enable the profiles you want to use for this protected resource. Select the profile, then click Enable.

    The default profile cannot be disabled. However, it is not executed if you have enabled another Word profile that matches your pages, and this profile comes before the default profile in the list.

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

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

  10. The cached pages affected by the rewriter changes must be updated on the Access Gateway. Do one of the following:

    • If the changes affect numerous pages, click Access Gateways, select the name of the server, then click Actions > Purge All Cache.

    • If the changes affect only a few pages, you can refresh or reload the pages within the browser.

Creating or Modifying a Rewriter Profile

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. Select one of the following:

    • To create a new profile, click New, specify a name, select a profile type, then click OK.

    • To modify a profile, click the name of the profile.

  3. Use the Requested URLs to Search section to set up a policy for specifying the URLs you want this profile to match.

    Fill in the following fields:

    If Requested URL Is: Specify the URLs of the pages you want this profile to match. Click New to add a URL to the text box. To add multiple values, enter each value on a separate line.

    And Requested URL Is Not: Specify the URLs of pages that this profile must not match. If a page matches the URL in both the If Requested URL Is list and And Requested URL Is Not list, the profile does not match the page. Click New to add a URL to the text box. To add multiple values, enter each value on a separate line.

    And Document Content-Type Is: Select the content-types you want this profile to match. To add a new content-type, click New and specify the name such as text/dns. Search your Web pages for content-types to determine if you need to add new types. To add multiple values, enter each value on a separate line.

    For more information about how to use these options, see Page Matching Criteria for Rewriter Profiles.

  4. Use the Actions section to specify the actions the rewriter must perform if the page matches the criteria in the Requested URLs to Search section.

    Configure the following actions:

    Rewrite Inbound Query String Data: (Not available for Character profiles) Select this option to rewrite the domain and URL in the query string to match the Web server. To use this option, your proxy service must meet the conditions listed in Possible Actions for Rewriter Profiles.

    Rewrite Inbound Post Data: (Not available for Character profiles) Select this option to rewrite the domain and URL in the Post Data to match the Web server. To use this option, your proxy service must meet the conditions listed in Possible Actions for Rewriter Profiles.

    Rewrite Inbound Headers: Select this option to rewrite the following headers:

    • Call-Back
    • Destination
    • If
    • Notification-Type
    • Referer

    Enable Rewriter Actions: Select this action to enable the rewriter to perform any actions:

    • Select it to have the rewriter use the profile to rewrite references and data on the page. If this option is not selected, you cannot configure the action options.

    • Leave it unselected to disable rewriting. This allows you to create a profile for the pages you do not want rewritten.

  5. (Not available for Character profiles) If your pages contain JavaScript, use the Additional Names to Search for URL Strings to Rewrite with Host Name section to specify JavaScript variables or methods. You can also add HTML attribute names. (For the list of attribute names that are automatically searched, see HTML Tags.)

    Fill in the following fields:

    Variable or Attribute Name to Search for Is: Lists the name of an HTML attribute or JavaScript variable to search to see if its value contains a URL string. Click New to add a name to the text box. To add multiple values, enter each value on a separate line.

    JavaScript Method to Search for Is: Lists the names of Java methods to search to see if their parameters contain a URL string. Click New to add a method to the text box. To add multiple values, enter each value on a separate line.

  6. Use the Additional Strings to Replace section to specify a string to search for and specify the text it must be replaced with. The search boundary (word or character) that you specified when creating the profile is used when searching for the string.

    To add a string, click New, then fill in the following:

    Search: Specify the string you want to search for. The profile type controls the matching and replacement rules. For more information, see one of the following:

    Replace With: Specify the string you want to use in place of the search string.

  7. Click OK.

  8. If you have more than one profile in the HTML Rewriter Profile List, use the up-arrow and down-arrow buttons to order the profiles.

    If you create more than one profile, order becomes important. For example if you want to rewrite all pages with a general rewriter profile (with a URL such as /*) and one specific set of pages with another rewriter profile (with a URL such as /doc/100506/*), you need to have the specific rewriter profile listed before the general rewriter profile.

    Even if multiple Word or Character profiles are enabled, a maximum of one Word profile and one Character profile is executed per page. The first Word profile and Character profile in the list that matches a page are executed, and the others are ignored.

  9. Enable the profiles you want to use for this protected resource. Select the profile, then click Enable.

    The default profile cannot be disabled. However, it is not executed if you have enabled another Word profile that matches your pages, and this profile comes before the default profile in the list.

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

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

  12. The cached pages affected by the rewriter changes must be updated on the Access Gateway. Do one of the following:

    • If the changes affect numerous pages, click Access Gateways, select the name of the server, then click Actions > Purge All Cache.

    • If the changes affect only a few pages, refresh or reload the page within the browser.

Disabling the Rewriter

There are three methods you can use to disable the internal rewriter:

Disabling per Proxy Service

By default, the rewriter is enabled for all proxy services. The rewriter can slow performance because of the parsing overhead. In some cases, a Web site might not have content with URL references that need to be rewritten. The rewriter can be disabled on the proxy service that protects that Web site.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. Deselect the Enable HTML Rewriting option, then click OK.

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

  4. Select the Access Gateway, then click Actions > Purge All Cache > OK.

Disabling per URL

You can also specify a list of URLs that are to be excluded from being rewritten for the selected proxy service.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > HTML Rewriting.

  2. Click the name of the Word profile defined for this proxy service.

    If you have not defined a custom Word profile for the proxy service, you might want to create one. If you modify the default profile, those changes are applied to all proxy services.

  3. In the And Requested URL Is Not section, click New, then specify the names of the URLs you do not want rewritten.

    Specify each URL on a separate line.

  4. Click OK twice.

  5. In the HTML Rewriter Profile List, make sure the profile you have modified is enabled and at the top of the list, then click OK.

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

  7. Select the Access Gateway, then click Actions > Purge All Cache > OK.

Disabling with Page Modifications

There are cases when the URLs in only part of a page or in some of the JavaScript or form can be rewritten and the rest must not be rewritten. When this is the case, you might need to modify the content on the Web server. Although this deviates from the design behind Access Manager, you might encounter circumstances where it cannot be avoided.

You can add the following types of tags to the pages on the Web server:

These tags are seen by browsers as a comment mark, and do not show up on the screen (except possibly on older browser versions).

NOTE:If the pages you modify are cached on the Access Gateway, you need to purge the cache before the changes become effective. Click Access Gateways, select the name of the server, then click Actions > Purge All Cache

Page Tags: If you want only portions of a page rewritten, you can add the following tags to the page.

<!--NOVELL_REWRITER_OFF--> 
.
.
HTML data not to be rewritten
.
.
<!--NOVELL_REWRITER_ON-->

The last tag is optional, and if omitted, it prevents the rest of the page from being rewritten after the <!--NOVELL_REWRITER_OFF--> tag is encountered.

Param Tags: Sometimes the JavaScript on the page contains <param> elements that contain a value attribute with a URL. You can enable global rewriting of this attribute by adding value to the list of variable and attribute names to search for. If you need more control because some URLs need to be rewritten but others cannot be rewritten, you can turn on and turn off the value rewriting by adding the following tags before and after the <param> element in the JavaScript.

<!--NOVELL_REWRITE_ATTRIBUTE_ON='value'-->
.
.
<param> elements to be rewritten
.
.
<!--NOVELL_REWRITE_ATTRIBUTE_OFF='value'-->
.
.
<param> elements that shouldn't be rewritten

Form Tags: Some applications have forms in which the <input>, <button>, and <option> elements contain a value attribute with a URL. You can enable global rewriting of these attributes by adding formvalue to the list of variable and attribute names to search for. If you need more control because some URLs need to be rewritten but others cannot be rewritten, you can turn on and turn off the formvalue rewriting by adding the following tags before and after the <input>, <button>, and <option> elements in the form.

<!--NOVELL_REWRITE_ATTRIBUTE_ON='formvalue'-->
.
.
<input>, <button>, and <option> elements to be rewritten
.
.
<!--NOVELL_REWRITE_ATTRIBUTE_OFF='formvalue'-->
.
.
<input>, <button>, and <option> elements that shouldn't be rewritten

3.8.6 Configuring Connection and Session Limits

The Access Gateway establishes connections with clients and with Web servers. For most networks, the default values for unresponsive connections and sessions provide adequate performance, but you can fine-tune the options for your network, its performance requirements, and your users:

Authentication time limits for inactivity sessions are configured on the contract and enforced by the Identity Server. For information about how to configure this limit, see Assigning a Timeout Per Protected Resource.

Configuring TCP Listen Options for Clients

The TCP listen options allow you to control how idle and unresponsive browser connections are handled and to optimize these processes for your network. For most networks, the default values provide adequate performance. If your network is congested and slow, you might want to increase some of the limits.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > TCP Listen Options.

  2. Select Enable Persistent Connections to allow the Access Gateway to establish a persistent HTTP connection between the Access Gateway and the browser. Usually, HTTP connections service only one request and response sequence. A persistent connection allows multiple requests to be serviced before the connection is closed.

    This option is enabled by default.

  3. Specify values for the TCP Listen Options:

    Keep Alive Interval: Determines when an idle connection is closed. If no application data is exchanged over a connection for this amount of time, the connection is closed. This value limits how long an idle persistent connection is kept open. This setting is a compromise between freeing resources to allow additional inbound connections, and keeping connections established so that new connections from the same device do not need to be re-established. The value can be set from 1 to 1440 seconds (24 minutes). The default is 300 seconds (5 minutes).

    Data Read Timeout: Determines when an unresponsive connection is closed. When exchanging data, if an expected response from the connected device is not received within this amount of time, the connection is closed. This value might need to be increased for slow or congested network links. The value can be set from 1 to 3600 seconds (1 hour). The default is 120 seconds (2 minutes).

  4. To configure the encryption key, select one or more of the following:

    Enforce 128-Bit Encryption between Browser and Access Gateway: When this option is selected, the Access Gateway requires all its server connections with client browsers to use 128-bit encryption. If the encryption key is less than 128, regardless of the cipher suite, the connection is denied.

    Enforce 128-Bit Encryption between Access Gateway and Web Server: When this option is selected, the Access Gateway requires all its client connections to Web servers to use 128-bit encryption. If the encryption key is less than 128, regardless of the cipher suite, the connection is denied.

    NOTE:These SSL listening options appear disabled if you are configuring the tunneling services.

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

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

Configuring TCP Connect Options for Web Servers

Connect options are specific to the group of Web servers configured for a proxy service. They allow you to control how idle and unresponsive Web server connections are handled and to optimize these processes for your network. For most networks, the default values provide adequate performance. If your network is congested and slow, you might want to increase some of the limits.

  1. In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers > TCP Connect Options.

  2. Configure the IP address to use when establishing connections with Web servers:

    Cluster Member: (Available only if the Access Gateway is a member of a cluster.) Select the server you want to configure from the list of servers. Only the value of the Make Outbound Connection Using option applies to the selected server.

  3. Select how the Web servers must be contacted when multiple Web servers are available. Select one of the following for the Policy for Multiple Destination IP Addresses option:

    • Simple Failover: Allows the next available Web server in the group to be contacted when the first server in the list is no longer available.

    • Round Robin: Moves in order through the list of Web servers, allowing each to service requests before starting at the beginning of the list for a second group of requests.

  4. Select Enable Persistent Connections to allow the Access Gateway to establish a persistent HTTP connection between the Access Gateway and the Web server. Usually, HTTP connections service only one request and response sequence. A persistent connection allows multiple requests to be serviced before the connection is closed.

    This option is enabled by default.

  5. To modify the connection timeouts between the Access Gateway and the Web servers, configure the following fields:

    Data Read Timeout: Determines when an unresponsive connection is closed. When exchanging data, if an expected response from the connected device is not received within this amount of time, the connection is closed. This value might need to be increased for slow or congested network links. The value can be set from 1 to 3600 seconds (1 hour). The default is 120 seconds (2 minutes).

    Idle Timeout: Determines when an idle connection is closed. If no application data is exchanged over a connection for this amount of time, the connection is closed. This value limits how long an idle persistent connection is kept open. This setting is a compromise between freeing resources to allow additional inbound connections, and keeping connections established so that new connections from the same device do not need to be re-established. The value can be set from 1 to 1800 seconds (30 minutes). The default is 180 seconds (3 minutes).

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

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

Configuring Connection and Session Persistence

The Access Gateway establishes three types of connections:

  • Access Gateway to browser

  • Access Gateway to Web server

  • Browser to Web server

The Access Gateway connections to the browser and the Access Gateway connections to the Web server involve setting up a TCP connection for an HTTP request. HTTP connections usually service only one request and response sequence, and the TCP connection is opened and closed during the sequence. A persistent connection allows multiple requests to be serviced before the connection is closed and saves a significant amount of processing time. To configure this type of persistence, see the following:

  • Access Gateway to Browser: Click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > TCP Listen Options and configure the Enable Persistent Connections option.

  • Access Gateway to Web Server: Click Devices > Access Gateways > Edit > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers > TCP Connect Options and configure the Enable Persistent Connections option.

The persistence of the browser to Web server connection is always enabled and is not configurable. This feature allows a browser to use the same Web server after an initial connection has been established. Most Web applications are designed to expect this type of behavior.

Configuring Web Servers

The Web server configuration determines how the Access Gateway handles connections and packets between itself and the Web servers. For more information about Web Server configuration, see Configuring Web Servers of a Proxy Service

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

  2. If your browsers are capable of sending HTTP 1.1 requests, configure the following field to match your Web servers:

    Enable Force HTTP 1.0 to Origin: Indicates whether HTTP 1.1 requests from browsers are translated to HTTP 1.0 requests before sending them to the Web server. If your browsers are sending HTTP 1.1 requests and your Web server can only handle HTTP 1.0 requests, you must enable this option.

    When the option is enabled, the Access Gateway translates an HTTP 1.1 request to an HTTP 1.0 request.

  3. To enable SSL connections between the proxy service and its Web servers, select Connect Using SSL. For configuration information for this option, Web Server Trusted Root, and SSL Mutual Certificate, see Configuring SSL between the Proxy Service and the Web Servers.

  4. In the Connect Port field, specify the port that the Access Gateway must use to communicate with the Web servers. The following table lists some default port values for common types of Web servers.

    Server Type

    Non-Secure Port

    Secure Port

    Web server with HTML content

    80

    443

    WebSphere

    9080

    9443

    JBoss

    8080

    8443

  5. To control how idle and unresponsive Web server connections are handled and to optimize these processes for your network, select TCP Connect Options. For more information, see Configuring TCP Connect Options for Web Servers.

  6. To add a Web server, click New in the Web Server List and specify the IP address or the fully qualified DNS name of the Web server.

    • New: To create a new Web server, click New. Specify the Web Server IP Address or DNS. Click OK to add the new Web server to the list or Cancel to discard the changes.

      After creating the Web server in the list, you can configure it as primary server and prioritize the list of Web servers based on your requirement.

    • Delete: To delete a Web server, select the Web server from the list, then click Delete.

      If you delete the selected Web server, then all the Web servers which are corresponding to the device in the cluster gets deleted.

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

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

3.8.7 Protecting Multiple Resources

This section describes how to create multiple resources for 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 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:

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 3-12 illustrates this type of configuration for three proxy services.

Figure 3-12 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.

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

Figure 3-13 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 3-13 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 3-13 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 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.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 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 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 the Access Gateway host. Figure 3-14 illustrates this type of configuration.

Figure 3-14 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 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 Creating a Second Proxy Service, and select Virtual for the multi-homing type.

Creating a Second Proxy Service

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

  2. In the Proxy Service List, select New.

  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 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 the 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. In the Administration Console, 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 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) 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 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.

    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 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 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. 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 3-15 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. In the Administration Console, 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.

The 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 the 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.

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

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 the 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. In the Administration Console, 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 Managing Reverse Proxies and Authentication.

      Reverse proxy names and proxy service names must be unique to the Access Gateway. Protected resource names need to be unique to the proxy service, but they don’t need to be unique to the 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.