Share via

About host address translation (HAT) in IAG portals

  • Article

Applies To: Intelligent Application Gateway (IAG)

A Whale Communication Intelligent Application Gateway (IAG) 2007 portal enables access to multiple Web applications by using host address translation (HAT). While users communicate with the external Web site to request, receive, and upload data to and from the applications they access via IAG, IAG transparently parses the requests and responses, using content-type parsers, and IAG manipulates the URLs in those transactions, on the fly. The parsers manipulate the data so that, to the user, all links to the applications that are enabled in the portal point to one host, the public host.

Manipulating data

HAT automatically manipulates all the headers in all requests and responses. The manipulation of the body of the transaction, however, depends on its content, as follows:

  • In requests, body data is manipulated in the following content types:

    • XML: text/xml

    • POST requests containing forms of the following type:

      application/x-www-form-urlencoded

  • In responses, body data is manipulated in the following content types:

    • text/<suffix>, where <suffix> can be any type of text, for example: text/html, text/css, text/plain

    • application/x-javascript (to a limited extent)

Note

If your applications require the manipulation of other types of content, you can configure additional content types.

In order to streamline the manipulation of body content to conform to your applications, you can configure the types of tags each parser manipulates, or you can add token-to-token replacement, search and replace, and signature-injection mechanisms for content that cannot be handled by the parser. You can also exclude parsing in irrelevant data, for performance tuning.

Tip

Because requests are always manipulated after they pass the filter’s content inspection, the inspection rules you configure for the trunk are not affected by the manipulation described here.

Manipulating URLs

The filter modifies the following types of URLs in body data:

  • Absolute URL: includes the scheme, the server name, and the full path to the page.

    For example:

    https://www.contoso``.com/resources/system/egap.htm

  • Absolute path: representation of the location of the page, relative to the server on which it resides.

    For example:

    /resources/system/egap.htm

  • Net path: the browser adds the path to the scheme used in the current URL.

    For example:

    //www.contoso.com/resources/system/egap.htm

The filter manipulates URLs of the types described above on their way out of the organization, by adding a unique signature. When an HTML file is received from an application server, the filter signs all the relevant links in the file.

The signature is composed of the following:

  • Unique Identifier. You can assign a unique identifier for the site during HAT configuration, as described in Configuring global HAT parameters in IAG. If you do not assign an identifier, IAG automatically assigns an identifier to the site the first time you configure a Portal trunk.

  • Encrypted Data, as determined by the filter.

  • Unique Identifier with an additional suffix, which indicates whether IAG uses Secure Sockets Layer (SSL) to communicate with the application server or not, in the following format:

    • <Unique Identifier>0

      IAG does not use SSL to communicate with the application server

    • <Unique Identifier>1

      IAG uses SSL to communicate with the application server

For example:

If the organization’s unique identifier is OurID, the encrypted data created by the IAG filter is xyz, and IAG communicated with the application server using SSL, the signature is: OurIDxyz/OurID1

In this example, if the filter receives a file from the server www.myserver.com, using SSL, and the file contains two links that require manipulation, it signs the links as follows:

Original Link Signed Link

https://www.myserver.com/a.html

https://<Public Hostname>/OurIDxyz/OurID1/a.html

/a.html

/OurIDxyz/OurID1/a.html

In this example, if the user requests the second link, the browser sends a request for the following URL:

/OurIDxyz/OurID1/a.html

The filter receives the request and translates the URL to the following:

/a.html

The filter then sends the translated request to the following server:

www.myserver.com

Processing requests

The filter processes incoming requests in the following order:

  1. Determines whether the requested URL is recognized. A recognized URL is either the portal homepage or a URL that was processed by the filter when the link was sent to the client.

    • If the URL is recognized, the filter goes on to determine whether the application which it resolved in the URL is configured for access via the portal, in the Applications list of the Configuration program.

    • If the application is in the Applications list, the filter manipulates the request header, as described later on in this flow.

    • If the application is not in the Applications list, the filter returns a “Server Error” message to the client.

    • If the URL is unrecognized, the filter checks whether it appears in the URL Replacement list.

    • If the URL appears in the URL Replacement list, the filter replaces the URL and then goes on to manipulate the request header, as described later on in this flow.

    • If the unrecognized URL is not on the URL Replacement list, the filter checks whether the HTTP request contains a WhaleHATCookie header. This cookie contains the server from which the last response was sent. If the WhaleHATCookie is found, the request is attributed to the server found in the cookie. The filter then goes on to manipulate the request header, as described in the next step.

    • If the HTTP request does not contain a WhaleHATCookie, the filter returns a “Request Error” message to the client.

  2. The filter manipulates the request header.

  3. The filter determines whether data manipulation is required in the body of the request, according to the content type.

    • If the request contains data that needs to be manipulated, the filter goes on to the next step.

    • If the request does not contain data that needs to be manipulated, the filter sends the request to the application.

  4. If the request contains data types that require manipulation, the filter checks whether the requested URL is configured so that body parsing is skipped.

    • If body parsing is required, the filter goes on to the next step.

    • If body parsing is skipped, the filter sends the request to the application.

  5. The filter runs the applicable parser on the data.

  6. The filter sends the request to the application.

Processing responses

The filter processes responses in the following order:

  1. Manipulates the response header.

  2. Determines whether data manipulation in the body of the response is required, according to the content type. (Content that never contains links, such as graphic files, is not manipulated, and the filter sends the response to the client.

Note

Data that is received from the application server in chunk mode is transformed to content-length.

  1. Once the filter establishes that the response requires manipulation, it checks whether the response is configured so that body parsing is skipped.

    • If body parsing is required, the filter goes on to the next step.

    • If body parsing is skipped, the filter sends the response to the client.

  2. The filter checks whether data change is configured, and if it is, performs the necessary changes. Data change is used for token replacement and for signature injection.

  3. The filter runs the applicable parser on the data, depending on the content type.. The parsers manipulate the data so that, to the user, all links to the applications that are enabled via the AAP point to one site—the public host, that is, the external website. By default, all tags that can contain links are parsed. You can configure additional types of tags to parse.

  4. If “Search and Replace Response Content” is enabled, the filter runs a search and replace parser on the entire content of the response, including tags that do not normally contain links.

  5. The filter sends the response to the client.