Freigeben über

UAG and stateless (non-browser) clients

  • Artikel

One of the challenges facing many customers is the need to publish an application to be accessed by stateless clients. Stateless clients are clients that are non-interactive, like a program running on an un-attended computer, and connecting to retrieve data automatically from another organization (a.k.a. Service application or B2B application). Other examples include:

  • Running a site crawler or search engine against a site published via UAG
  • Connecting to UAG with an application that is not a browser*
  • Publishing an application with components that run outside the browser**

Some customers attempt to employ UAG for this type of scenario, using an unauthenticated trunk:

image

Essentially, disabling trunk authentication in the Advanced Trunk Configuration turns UAG into a transparent proxy, providing functionality comparable to using a Server Publishing rule in TMG. However, some users have run into issues with this scenario. The issue presents itself as a “loop” experienced by the application when it tries to access a URL through UAG, or a 500 error returned by UAG. When a loop is experienced, Instead of getting the expected HTML data from the backend server, UAG replies with a redirect to the InitParams.aspx page, followed by a redirect to the InternalError.asp page, with error 109. As the application requests the Internal Error page, UAG replies to that with another redirect to the InitParams page, and this loops indefinitely, or until the application decides to stop following the redirects.

The reason this is happening is because UAG is designed to interact with browsers*, and part of this interaction is the session cookie issued by UAG. When a client creates a new connection, UAG will issue such a cookie, and will expect it upon subsequent connections. Even a connection without authentication requires some interaction with UAG (the session parameters initialization page mentioned earlier), and that means that if a client is unable to store the session cookie, respond to HTTP redirect commands and reply with the cookie upon subsequent requests, UAG will not be able to service it.

This mechanism is part of UAGs design, and is a security mechanism that cannot be disabled. This means that stateless clients need to meet those requirements in order to be able to interact with UAG. Depending on the application and the platform it was built on, this change could be simple. Unfortunately, though, if the application cannot be made to behave this way, UAG will not be able to provide it with access, and the only alternative is to use TMG (or comparable firewall publishing solutions) instead, or the publish the application using SSL-VPN**. I should also note that the list of supported clients for UAG is listed here, and other clients are unsupported. This means that if you are creating your own client, even if it runs on a supported platform, it is not automatically supported by UAG. If it’s built well and in accord with public internet RFCs, it should work, but that is not guaranteed, and is not supportable by Microsoft.

* There are some exceptions to this. For some scenarios, UAG does behave differently. Once such exception is the interaction with office applications, which are considered to be “rich” clients, and have another mechanism to interact with the back-end server (SharePoint) via UAG.

** Client applications that cannot interact with UAG the way a browser would may still be usable by publishing the application using tunneling. This way, the client computer has an SSL-VPN tunnel, which allows the client app to interact directly with the backend server, without going through the UAG publishing engine. This is not always a suitable solution, because it does require the client to connect to UAG with a browser, establish a session and launch the SSL-VPN tunnel. For non-interactive services, such as B2B applications or site-crawlers, this is usually not possible at all.

Comments

  • Anonymous
    January 01, 2003
    Ben! You're awesome, we had been working on an issue for a month or so and this post was the exact answer we needed, thank you!
  • Anonymous
    January 01, 2003
    Ben! You're awesome, we had been working on an issue for a month or so and this post was the exact answer we needed, thank you!
  • Anonymous
    January 01, 2003
    This just saved us with one of our customers. Thanks so much for the information!
  • Anonymous
    November 12, 2015
    I can only say, You are Awesome!!!