Publishing web applications though IAG : what if it fails ?


Microsoft IAG (Intelligent Application Gateway) is a powerful “mobility” gateway capable of providing remote access to different kind of people: employees, partners, customers, …

It introduces several approaches to provide this mobility:

·        “Reverse proxy”: this is the most common scenario, for Web applications. This is the strongest approach since IAG can do a lot of inspections, and provide “application layer” security to cope with cyber criminals attacks.

·        “Port forwarder”: technology dedicated to TCP applications (called Legacy applications in IAG). It provides “sort of VPN/SSL” but without virtual NIC and private IP. The very nice thing with that approach is that if you have a malicious agent (unfortunately) on the client-machine, since there is not “IP connectivity” with the company, this bad guy cannot enter attack your network. He will never enter the “port forwarder tunnel”.

·        “VPN/SSL” called “network connector”: this is the same approach as other VPN/SSL solution on the market, you see a virtual NIC, and you get a private IP. Your machine is then virtually plugged on the company’s network, and you have access to the company’s network like all the other machines on the physical LAN. Mostly a solution when remote machine are “corporate/managed” ones.

Let’s put aside for a second the scenario where you want to plug that remote machine on the network (VPN, VPN/SSL), and let’s focus on web application publishing (reverse proxy) approach which is the purpose of this article.

When you publish an application with IAG, you use a wizard where you can select the application you want to publish. By default, you have in the GUI a long list of business applications: all Microsoft products of course (including MOSS, OWA, …) but also non Microsoft products such as Lotus notes, SAP, …

pic1


Figure 1 - IAG GUI, add an application

For such “business” applications, it takes 3 seconds to publish through IAG, and then you can leverage all the good security features in the product such as strong HTTP firewalling, workstation inspection, security policies, …

What if the application is not in this list?

When you publish an application that is not in the list, you can use a generic template called “Generic Web App”. For most of the web application, this standard template will just work fine. Unfortunately, some of them will fail. Symptoms can be different depending on the application:  broken links, error messages on the page, … Let’s see why we have this behavior.

Back to the basics: what is a “web” application?

When we say “Web” we quickly have in mind the notion of HTML.

With HTML language, we tell the browser what to do such as display text, change the font and size, put in bold… but also can add some clickable links to provide access to other pages, etc.

Once this HTML page is rendered by the browser, we have a nice page displayed and understandable by a user. Here is a screenshot taken from Microsoft Expression. You can see on the top the HTML code, and in the bottom the result when it is rendered by the browser:

pic2

Figure 2 - HTML page once rendered by a browser

In this example you have several basic HTML tags such as one used to display text, add pictures, add links, but in bold or change the color.

What is the challenge?

But that “HTML-only” approach was nice 10 years ago when internet started to grow. Nowadays technology is different and more complex. We still have HTML that rules the structure of the page, but we have a lot of other technologies injected in this HTML page: javascript, java, Silverlight, etc.

What is the most important to illustrate the purpose of this article in the previous screenshot is the link to www.microsoft.com. In HTML you create a link by using an “HREF” HTML tag.

In a web publish scenario, all the reverse proxy (including IAG) will change the internal URL (for example http://financeApplication.internal.private) into something compatible with the internet (https://financeapplication.company.com), because they are able to understand HTML, and because HTML structure is predictable. We call this “link translation”.

So when the page will go through the reverse proxy, an internal engine in the Rproxy will “modify” the HTML page, to make it compatible with reverse proxy publishing and update the links from “internal names” to “internet names”. It will work perfectly.

But nowadays, the page can contain lot more than HTML code. It can also contain javascript code and this code that can do pretty much anything (in fact what the programmer want to do with it). More than that, most of the “javascript” developers now base their coding on top of a “javascript framework” (Here is a page that lists a lot of Javascript framework: http://edevil.wordpress.com/2005/11/14/javascript-libraries-roundup/).

So what is the problem here? Well, in HTML reverse proxy just have to locate “HREF” tags in the page and update the links, but what if the page is generating this link via a javascript, or more frequently, what if the code is generating itself the HTTP GET ? Here is a fake example of code located in a demp HTML page:

Var myvar1 = “http”;

Var myvar2 = “financeapplication”;

Var myvar3 = “internal.private”;

// request sent to  http://financeApplication.internal.private

HTTPget (myvar1+”://”+myvar2+”.”+myvar3);

 

In this example, the “HTTPGet” Javascript function will generate an HTTP get on an URL composed by  3 variables and 2 hardcoded strings. The “value” passed to this function will be “http://financeApplication.internal.private”, but it will be “calculated” on the client-side once the browser will render this page. This means that the reverse proxy will be blind, will not be able to analyze this code, just because he is not able to identify it, and so will not change anything : this code will fail through a reverse proxy.

How to fix that with IAG?

First of all, I have bad news and good news for you.

The bad news is that usually we want computers and software to do “magic” for us, which is in our scenario “fix the problem yourself Mr Reverse Proxy”. This is the bad news since it is not possible, just because the source of the problem is the way that the developer is coding his page, and this is not “predictable”. A “dumb machine/software” cannot do that if we cannot teach it how to do so.

The good news is that IAG can help you a lot to fix that problem. It will not provide “magic”, but a strong engine that will give you the appropriate tools to make that reverse proxy access working. How ?

Step 1 of the solution will be your job IT People. You will need to capture HTTP traffic (using products such as HTTPwatch or Fiddler) and locate the problem, I mean here the URL which contains the code that cause the problem.

Step 2, when you know where it is breaking, you will tell IAG what to search and what to change in this page when this page goes through it, in our example the Javascript. You will update this Javascript to make this application “reverse proxy publishable” (Uggly) which means in our example update this part of the code :

Var myvar1 = “https”;

Var myvar2 = “financeapplication”;

Var myvar3 = “company.com”;

// before : request sent to  http://financeApplication.internal.private

// after : request sent to  https://financeApplication.company.com

 

HTTPget (myvar1+”://”+myvar2+”.”+myvar3);

 

90 % of the job is yours IT People: ability to capture, analyze and identify what is breaking. The remaining part will be only to tell IAG what to do to fix the problem.

In fact, you will tell IAG’s engine called “ApplicationWrapping/SRA” via a configuration file (XML) how to fix that, pretty much what to “search” in the page and what to “replace”.

How hard it is to fix that ?

The problem (code breaking with reverse proxy) we are facing is in fact pretty challenging for most of the IT people. The reason is that you can be an expert in network but not in development, and vice versa. And such problem requires a bit of experience in both areas.

When you face such problem, you will need to analyze the traffic in order to understand how works the HTTP traffic (GET, POST.. error code, cookies) and also have some basic notion of dev (very basic) just to feel not afraid about what you see.

The first experience you will get on this will be hard, especially if you want to learn everything alone. I would definitely advise you to talk to someone trained to do such thing, and go through a course. Usually after a 1 day training (where we re-introduce HTTP, Scripting, how to capture traffic, how to configure IAG) you feel better, and you have discovered the “application layer” world where most of the challenges are nowadays, and where most of the security risks are located (cyber criminality).

Based on my experience, most of the applications breaking take a few minutes/Hours to get fixed. On the opposite, some others are very big and complex, and will take days, but they are rare. At the end of the day, do you have the choice ? if you don’t fix this, you need to have a “network layer” approach (VPN or VPN/SSL) then security will be lower, and you will not provide access to partners and customers with such approach.

Keep in mind that most the “IAG” certified partners are trained on this and can help to fix the problem, or help you to ramp up on such approach.

Learn by example

I personally had to face several applications like that in my day to day activity. Every time I can, I provide some feedback in my blog. Go to my blog (http://blogs.technet.com/fesnouf/) and click the “howTo-Filters” tag for examples.

Comments (0)

Skip to main content