Skip to main content

Cloud

A Walkthrough of ISA 2006 Link Translation Capabilities

We recently had a customer that was looking to do some pretty sophisticated URL and link translation and wanted to know it if could be done with ISA 2006. Here were the requirements:

Inbound URL: http://www.abc.fr/directoryA/somepage.aspx

Internal URL: http://www.abc.local/directoryB/somepage.aspx

Returned to user in browser address line: http://www.abc.fr/directoryA/somepage.aspx

Inbound URL: http://www.abc.jp/directoryC/somepage.aspx

Internal URL: http://www.abc.local/directoryD/somepage.aspx

Returned to user in browser address line: http://www.abc.jp/directoryC/somepage.aspx

The above pattern needed to be repeated across many countries (.de, .ca, .au, etc…). Needles to say, this generated a good deal of internal conversation on the best way to tackle it and I thought it might be helpful to share what we learned.

DISCLAIMER: This example uses a Reporting Services page and I’m sure things get at least a more complicated with SharePoint 2007. It may even break stuff. But what is outlined below should at least help clarify what ISA 2006’s capabilities are in this space and help guide you with any evaluation you may be doing. It goes without saying that any attempt do customized URL and link translation with a SharePoint 2007 infrastructure will require thorough testing prior to bringing anything to production.

This particular topic can be broken down into four functional components: (1) Inbound domain name mapping, (2) inbound directory path mapping, (3) translation of outbound server-generated links, and (4) inbound URL redirection. Here goes….

PART 1: INBOUND DOMAIN NAME MAPPING

To start with, I published my reporting server, which is internally known as http://adat150.adatum.local, using a standard web publishing rule.

clip_image002

I then added publicly known Fully Qualified Domain Names (FQDNs) for each country. This is done in the “Public Name” tab of the Web Publishing rule.

clip_image002[9]

So in this example, external users may access the internal reporting server via http://abc.de/path, http://abc.fr/path, or http://abc.mx/path. All three work just fine for the published server and the end-user only sees the FQDN that he or she entered. This satisfies one requirement: www.abc.fr (external) to www.abc.local (internal). So far so good.

PART 2: INBOUND DIRECTORY PATH MAPPING

The next requirement is to map the directory underneath the FQDN: /directoryA/ (external) to /directoryB/ (internal). This is accomplished on the next tab over (Paths). In this example, I’ve configured ISA to publish the /reports directory on my Reporting Services server as /myreports to the external end-user.

clip_image002[4]

NOTE: The minute you go this route, the default External Path and Internal Path mappings (<same as external> to /*) must be removed and going forward all other directories need to be explicitly defined. The default wildcard setting that maps the end-user directory with the actual one on a 1-to-1 basis can no longer be used. If you try to add it back, you’ll see the following error. Make sure you understand the ramifications with this.

clip_image001

PART 3: TRANSLATION OF OUTBOUND SERVER GENERATED LINKS

All of the above would works…to a point. We know that SharePoint and other applications return data referencing internally-generated links. Things like graphics, layout information, and such. The below screenshot is what happens with all of the above configured. Notice the URL on line 19 and the URL in the address bar do not align. Not pretty.

clip_image002[7]

So what do you do? Everything that we’ve dealt with so far only handles inbound translation (external user to Web Server). We need to do the same for outbound translation (Web Server to external user). So the next step is to enable Link Translation for the publishing rule:

clip_image002[12]

…then set up a local mapping by clicking “Configure…”

clip_image002[14] clip_image002[16]

As you can tell, the jargon here is quite confusing. Keep in mind that Locally Defined Mappings and Dictionary Items are all about outbound traffic, so here I’m replacing the text “Reports” with “myreports” for all links coming from the published server that is part of this rule. This would need to be done for each mapping that you want to support.

After setting this up, here is what you get. Much better.

clip_image002[18]

NOTE: You do not need to set up translation of the FQDN (Part 1 above). ISA 2006 is smart enough to do that for you.

PART 4: INBOUND URL REDIRECTION

Recall that overriding the default external and internal paths leads to a situation w
here the user *must* enter in a legitimate path that you defined in Step 2 (above) after the domain name in order to get to the web server. I’m sure everyone would agree that this is not realistic. So how do you provide a more user-friendly method for gaining access? Well, it turns out the answer is to create a second web publishing rule that is specific for each domain, explicitly define illegal paths such as the root, and set it to deny access. In ISA 2006, when you set a rule to deny access, you get the option to redirect to a different URL.

clip_image002[20]

clip_image002[22]

clip_image002[24]

You typically put the deny rule right before actual publishing rule that we worked on earlier.

clip_image002[26]

So with this example, I can access the Reporting Services site via: http://abc.de, http://abc.de/reports/, and http://abc.de/myreports. The first two examples will result in a re-direct to the third. The /myreports/ path is translated to the actual /reports/ directory on the Web Server…both inbound and outbound.

CONCLUSION

So is this a practical example that is likely to be seen out there in the real world? I’m not sure. But hopefully this walkthrough does shed some light on some of the link translation capabilities of ISA 2006 and how they could be potentially leveraged in certain publishing scenarios. At a minimum, a decent understanding of these concepts should help keep you from banging your head against a wall in the event you need to do something like this. 😉

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Travis Nielsen

More from this Author

Follow Us
TwitterLinkedinFacebookYoutubeInstagram