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:
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 http://exchange/owa/14.2.283.4/themes/resources/lgntopl.gif, the browser will try http://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 http://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.
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.
Clear crisp explanation.