When a user types in the URL for a UAG portal, the client computer resolves the URL to an IP address (using DNS or a HOSTS entry, typically, or via his/its defined proxy) and the request is sent to that IP. Then, on the UAG server, TMG receives this client request and cross references this against its firewall policies to ascertain whether the connection should be allowed or denied. If accepted, the request is then sent over to IIS, and in turn to UAG's ISAPI filter for processing.
The ISAPI filter is responsible for an incredible amount of work, some of which can be observed from the output of a UAG trace taken during a client session. What actually goes on during the Client/Server interaction is far too complicated to fully explain here, but at a higher level, a client connects and the filter checks for cookies, essentially looking for one that will identify the user against an existing UAG session. If one is not found then the filter issues a redirect, sending the user to the standard form-based portal login page.
Note
An exception to this is when the request is coming from rich client applications, such as Outlook, ActiveSync, or the various other Office applications, for which authentication can be performed directly (assuming, of course, that the portal has been configured for this method of publishing).
This login page (part of the InternalSite site) forms a part of the core authentication mechanism used by UAG, and to which all trunks rely on for various aspects of access to the portal, such as the endpoint detection and the authentication flow. Creating a new trunk in UAG also creates a new virtual website within IIS with the same name as the trunk. Why would the portal login page be referred to as Internal, even though it's really external? Well that's because historically, when e-Gap was created, the solution actually comprised of two distinct physical servers. Back then, instead of TMG, there was the external server and the internal server. The external server would transfer session data to the internal server, using a hardware-based device that interconnected the two devices, while offering the highest level of data isolation for its generation. The architecture here was clearly of a different nature when compared with UAG, but certain key components were already being used, such as IIS. The key differentiator was that you had two separate instances of IIS, one running on each server. The external one didn't do much work, but the internal one, on the other hand, was where the clever stuff really happened. A lot of that code is still with us today; hence the terminology.
So, in the case of a session cookie not being detected, the browser would be redirected to the login page, but beforehand, UAG will run through its install-and-detect phase, in an attempt to determine whether the client already has the UAG client components installed. Its failure to detect the components would prompt the user with the option to install them or to continue with limited functionality. However, the existence of the components would simply allow UAG's detection routine to initialize and call upon the default detection script (\von\internalsite\detection.vbs), which collects endpoint information and sends it back to UAG using the results function (more about detection is discussed in Chapter 3,Customizing Endpoint Detection and Policies
At this point, an unauthenticated session can be seen in UAG's Web Monitor, and by now UAG has already associated this connection with a unique session ID, represented as a GUID. It's the information that was collected during the detection process that will determine the level of access that the user is granted for any particular session, and the results can be viewed within the Parameters tab as illustrated in the following screenshot:
 |
As you can see in the preceding screenshot, the Lead User and Repository have yet to be populated as the user has not logged in, and this is also represented by X in the Authenticated column.
It's UAG's advanced policy engine that allows for the creation of extremely granular policies that can be enforced across several different levels. Since UAG trunks have their own individual access policies, we have the ability to evaluate a client's request for access based on what was found during detection. A decision can then be made to permit access according to whether or not a client was able to satisfy a given set of configured security policy requirements. One of the collected parameters is the user-agent, which is what a client's browser will send as part of the initial connection process. This string alone is what helps UAG acknowledge the type of endpoint that is connecting, and in turn which of the four core OS policies to apply Windows, Mac, Linux, or Other (which would typically be a phone of some type, or an iPad). Each of these core policies then also have individual subpolicies that are constructed for a specific operating system, so accurate detection of the type of client is a critical part of this deterministic process.
UAG will evaluate policies using the Boolean logic, so as with the preceding screenshot, you can expect to see a TRUE or FALSE against many parameters. In general terms, the majority of the results shown on the Parameters tab are returned from the default detection script previously mentioned. However, custom policies will also show in this list, and how UAG perceives the returned response can be configured in any number of ways. So, you could expect the results of an endpoint policy evaluation ending concluding with FALSE to then redirect a user to the access-denied page.
As part of the login flow, a user will be redirected to the validation page (/InternalSite/Validate.asp), which triggers UAG's authentication mechanism. Depending on the authentication configuration set on the trunk (repository type and settings), UAG contacts the authentication target and validates the user. UAG will also collect additional info, like password expiry and group membership. If the repository is of the Active Directory type, then directory queries using ports 389, 636, 3268, or 3269 will take place, but the actual method used can also change depending on how this is configured. Using the option of querying the DCs directly will instruct UAG to query two explicitly defined domain controllers, whereas using the Forest alternative will enumerate all DCs using Global Catalog services and ports.
Assuming the user's credentials have been accepted, they are then encrypted and stored in UAG's allocated address space, and linked to the authentication repository the user has used, for the duration of that session. If there are applications that have granular authorization settings based on group membership (as opposed to being set to Allow all users on the application's Authorization tab), then UAG will cross check the user's saved domain group membership info against those set for the application to control access and visibility of the application icon within the portal.
At this point, the endpoint policies now come back into play. As with trunks, each application also has its own policies, and these can be used to control which applications will be available to the user. For example, Macintosh and Linux computers do not have all the required endpoint components to support all applications types, so UAG will detect that and prevent access to certain types (RDG-based applications, for example). After the decision process, the user is then redirected to the original URL he initially typed. If that URL is the UAG's root URL, then the redirect would go to the initial application defined on the trunk. This would usually be the Portal itself, or some other application, if so configured by the administrator.
Once a user has a valid session, he may stare blankly at the screen for a bit, but at some point, he would typically want to launch some application. When the user clicks on an application on the portal, or clicks on a link within an application that is already launched, his browser creates the request and passes it on to UAG. When the filter receives the request, it analyzes the request host header, cookies, and other header information, before trying to determine to which application the request belongs.
UAG may have applications published using the portal hostname method, and others using the application-specific hostname such as with SharePoint. Using the host header included in the request, UAG tries to determine if there are application-specific hostname applications that match that host header, or perhaps the host header matches the trunk's public hostname itself. This, however, isn't foolproof, so UAG has other ways of associating a request to an application, such as looking at the HAT signature itself (more on that later). Another method is to examine the path of the URL, to try and match that against the paths defined within the various applications. There are additional methods, such as the possibility to decide based on the HAT cookie, if such a cookie was received along with the HTTP request, and the Manual URL Rerouting (MUR) rules, which help UAG decide where to send an otherwise unrecognized request. If none of these have helped and a match is not found, then UAG will redirect the user to an error page.
The following screenshots illustrate the differences between these two common types of applications one listing a public hostname and the other has certain paths defined for it:
 |
Once UAG has identified the application the request pertains to, it then initiates the same resource request to the real application server, as defined in the Web Servers tab of the application configuration. This process may involve some adjustment of the host header used in the request, if the target application dictates it (this is common with SharePoint applications).
The request is sent to the backend server anonymously, and if the backend server is configured to accept anonymous requests, it would send back an HTTP status code of 200 OK, and an HTML page with content. This, however, doesn't always work out.
If the backend server is configured to require authentication, it will typically respond with something other than the page requested. Most commonly, it would return an HTTP status code of 401, also known as unauthorized. This triggers UAG's SSO mechanism, and it will fetch the user's credentials from its memory, where they were stored when the user logged in and resend the same request, with the credentials. Usually, the backend server will accept it, and then reply with the content requested. Occasionally, it may not like the credential set, and again reply with a 401. This could happen if the authentication scheme was not set correctly on UAG.
For example, if the backend application server was configured for Kerberos authentication, the application on UAG needs to be configured for that as well (in addition to other Kerberos Constrained Delegation (KCD)-related trust and delegation particulars). In such situations, UAG retries the authentication a few times, and then gives up and redirects the user to an error page.
Another situation is when the backend application is configured for Forms-Based Authentication (FBA). In this case, the application will deliver back an HTML page with a login form of some sort. UAG has a forms-processing engine, so if a configuration exists for it to identify and work with that form, it will process it and respond with the client's credentials. UAG comes pre-configured to handle some applications' forms out of the box, such as SharePoint, Citrix, and others. An administrator can also create a custom configuration for this, and we will discuss this in Chapter 8, Extending the Login Process with Customization. It's UAG's ability to recognize a form's structure that allows it to inject a user's credentials, while also adding the necessary JavaScript into the page to simulate a user clicking on the Login button. Some forms do not use a generic or conventional way of doing things, so this is where we can extend UAG's functionality to incorporate additional form data that it may not currently be aware of.
The one key dependency that UAG SSO relies on is that both parties, UAG and the target application server, are configured to mutually agree on a common authentication scheme during the challenge response process. Thus, in most cases, this is somewhat as simple to set up as configuring the appropriate authorization type at both ends, and UAG will do the rest. In some scenarios, things can get a little more challenging. This is where we can really capitalize on UAG's flexibility.
As mentioned, pairing up a client request to an application is critical to UAG's functionality, and the HAT mechanism is a big part of that process for applications that are not using the application-specific mechanism (like SharePoint or Lync publishing). The way it works is by trying to have requests that come from clients bearing a unique signature that will help UAG identify to which application it belongs. To that end, UAG, when it delivers an HTML page to a client, will parse the entire page contents for links and references, and where possible will try to add a unique signature to each of them. The unique signature itself is an alphanumerical hash of the properties of the backend server it pertains to.
As part of this process, UAG places the HTML page into a special buffer in memory and starts parsing it, looking for various HTML and JavaScript elements in the text. For example, it may identify a link to an image that uses the format<IMG SRC="angry.gif" ALT="Angry face" />, and insert the unique signature after SRC, resulting in the tag similar to the following:
<IMG SRCc="/uniquesigf872a75338c81cc6d2bc458e795f24b8/uniquesig0/angry.gif" ALT="Angry face" />
After all the changes, the altered HTML is delivered to the client. If all the links and references have been identified and signed, subsequent requests pertaining to this application will all carry the same signature, which in turn allows UAG to easily intercept and handle requests on a per application basis.
Naturally, the process may not always go smoothly. UAG has been designed to handle pretty much every possible HTML tag, as well as common JavaScript structures, but there could always be a miss, and that is something you may need to handle. We will discuss using a custom SRA or Application Wrapper configuration file for this sort of situation in Chapter 4,The Application Wrapper and SRA