Before we go into discussing the customizations, we need to explore and understand some basic concepts of customization in general, as well as UAG-specific customization technologies and operability. Throughout this chapter, we will also discuss some of the technologies that UAG relies on, such as HTML, JavaScript, ASP, and ASP.NET, so you can judge if your knowledge of these technologies is sufficient or requires further reading. In this chapter, we will discuss the following topics:
Introduction to UAG and how it works
The UAG detection, login, and authentication flow
Customization and supportability
The
CustomUpdatemechanismHTML, CSS, JavaScript, ASP, and ASP.NET
Other web technologies
Reading, editing, and debugging ASP code
A word about security
Further reading
Ah! Don't worry, we have no intention of boring you with a lesson on reverse proxies — we're sure you've been through that till all your IPs got released. However, you do need to have a clear understanding of UAG and the actual flow of information between various components so you can figure out where best to inject your own stuff.
At the heart of UAG is its main component, the WhlFilter.DLL, which is an ISAPI filter and extension. When you install UAG on a Windows Server, it plugs itself into IIS, meaning that every UAG-related request that passes through this IIS server gets handled by our DLL, and that's when the magic happens. The UAG management console acts as the interface between yourself and the complex backend configurations that get applied when you hit the activation button. Once committed, your configurations are what control how the ISAPI filter behaves in terms of processing requests, headers, content, and the overall security characteristics.
Significant parts of the UAG framework are written using ASP, and these include the UAG login, logout and authentication dialogs, the error-handling mechanism, the endpoint detection, the web-monitor, and more. Then we have the management console itself, which is compiled code. Naturally, UAG has many other components to it, which are less visible to the naked eye.
So where does UAG store its settings and configurations? This can really depend on whether this is a standalone server or an array, but in a standalone deployment the core of the main configurations are stored in two key locations:
In a text-based EGF file (stored in
<UAG Path>\common\conf\UAG.egf)As a binary vendor parameter in TMG storage (AD LDS)
Other data that is equally important is also held in various XML files within the UAG folder hierarchy, but UAG can be particularly sensitive about it is the two aforementioned data stores. This arrangement still applies in an array configuration but the difference to note here is that the Array Management Server (AMS) will be the one that holds the master configurations for all of the array members. So although each node will have a local copy of the EGF file, they will all rely on the AMS to obtain settings that are common to all members. The configuration stored as part of the array includes custom files that the administrator may create as part of the customization process. Occasionally you might run into certain flags that are stored directly in INC or ASP files, such as the InternalSite site trace flag, which tells UAG to trace the ASP code (more about that at the end of this chapter).