What is HAT, and how does it work?

One of the most important things that UAG does is the host-address translation, also known as HAT. This is visible as a long alpha-numeric string of characters that is part of URLs seen on the client when using UAG. It’s important to understand how this mechanism works, and what it provides us with.

The HAT mechanism goes back many years, to UAG’s predecessors IAG and e-Gap, and it’s still with us today and doing a good job. The purpose of it is to allow UAG to publish many internal applications and servers using a single public hostname and IP Address. After all, IP addresses are expensive, and we want to publish all our internal web servers using as few as possible. With other publishing mechanisms, you would need one IP per application, and that is not only wasteful, but harder to manage.

To address this, UAG has the UAG portal, on which you publish the multiple applications. The challenge here, though, comes from the fact that internal applications are usually not designed to co-exist on a single server. A typical application server, such as Exchange, would generate HTML content designed to be accessed from the internal network. For example, it could contain references to image files, like this:

This simple HTML tag references an image on the internal web server “exchange”. When the client browser reads the page, it will automatically try to download all the resources referenced in the page. This could be images, JavaScript files, CSS files etc. In the above example, it will try to contact the server “exchange” to fetch the two images lgntopl.gif and lgntopr.gif. However, if the client is on the public internet, it will fail to resolve the hostname “exchange”, as that server is not available on the home user’s network or on the public internet. The result will be something like this:

In every place there’s a link to an image, the browser will fail to load the file and show an X instead.

To address this, UAG edits the content of the HTML on-the-fly, before it’s delivered to the end-user, and changes the referenced server to its own public URL, like this:

So now, instead of trying to load https://exchange/owa/14.2.283.4/themes/resources/lgntopl.gif, the browser will try https://mail.microsoft.com/owa/14.2.283.4/themes/resources/lgntopl.gif . This request will reach UAG, and here comes the next problem…how will UAG know to which of the applications it publishes this pertains? After all, UAG’s public hostname is the same for all applications, so it may not know if this request should go to the Exchange server, or to some other server. This is where HAT comes into play. To help itself identify the request, UAG attaches a unique number to each request, as it goes out. This is like a dry-cleaning service giving you a voucher when you give them a coat. Based on the unique number in the voucher, they can find it later on their rack.

To facilitate this, UAG generate a unique number, based on the name of the internal server this pertains to. If it is going to send you an HTML fetched from https://exchange, it will generate a “signature” that’s unique, and “sign” the HTML in addition to translating the server name itself. The result would be something like this:

Now, when the client tries to fetch the file, UAG will decode the string, and know to which server it should talk to in order to get the file.

To perform the signing operation on HTML sent to the user, UAG has a special engine called “SRA” (Secure Remote Access), which contains a list of various HTML and JavaScript tags. This allows UAG to understand the structure of the page, and to know where to look for references to files. For example, here’s a piece of this configuration file:

As you can see, the above has info about the HEAD, IFRAME, ILAYER, IMG and INPUT tags. The rest of the file has several hundred other tags, and their various possible attributes.