Configuring IAG URL rules when application URLs contain variables

Article
02/10/2010

Applies To: Intelligent Application Gateway (IAG)

This topic describes how you can configure URL inspection rules, where the path of the application URL includes a user-dependent variable. In this manner, you can ensure users are only granted access to the portion of the application for which they are authorized, and the same user is logged in throughout the session (for example, organizations where users are allowed access to their department’s database only, or implementations where users need only access a specific URL set and the login user name is part of the URLs they are trying to access).

Using variables in URLs

In order to configure a user variable as part of the URL, you have to take the following steps:

For each application where you wish to use variables, create a rule set that contains the variable.
For each trunk where you wish to use variables, configure the authentication pages.
For each application where you wish to use variables, activate the option Use Variables in URLs in the Web Settings tab of the Application Properties dialog box. For more information, see Managing applications published in an IAG portal, and Configuring Web site settings for an application published directly by IAG.

Limitations

Before you configure this option, take note of the following:

You can only configure one user parameter per application; each URL can contain one instance of this parameter. You cannot configure the following examples:
- /exchange/mark/inbox/mark, where the dynamic user name mark appears twice in the URL path
- /exchange/benjamin/sean/calendar, where two dynamic user names, benjamin and sean, are part of the URL path
When configuring repetitions, you must take extra steps f a value of a dynamic, user-dependent URL parameter also appears as a portion of the URL path prior to the dynamic parameter.

Repetition examples

Example 1: Outlook Web Access in Exchange 2000

Take a look at the example used in "Creating a rule set using a variable". Let’s say one of the values of the dynamic user parameter is the user name chang. Note that chang also appears in the URL path, as part of the word exchange. In this case, you have to take the following steps:

Example 2: Domino Web mail

In this example, we are creating a rule to accept the following URL:

/ToDo/User_Name.nsf/Weekly

Where the rule’s URL looks like this:

/ToDo/< UserName >\.nsf/Weekly

However, if one of the users in this example is “tod”, note that “tod” also appears in the URL path, as part of the word “ToDo”. In this case, you have to take the following steps:

In the URL Set tab, edit the rule’s URL and take out the file extension (.nsf) after the dynamic parameter. In our example:

/ToDo/<UserName>/Weekly
In the authentication page, edit the ParamVal line as follows:

SetSessionResourceParam g_cookie, <Application_ID>, “ParamVal”, “Parameter_Value”+”.nsf”

For example:

SetSessionResourceParam g_cookie, <Application_ID>, “ParamVal”, Session(“user_name1``”)+”.nsf”

Creating a rule set containing the variable

In the URL Set tab of the Advanced Trunk Configuration window, under URL List, create a rule with an Accept action. Under URL, enter a URL where the user variable is represented by a “symbol” parameter; note that the symbol parameter has to be enclosed by angle brackets, as demonstrated in the examples that follow.

For instructions about creating a rule, see Configuring IAG URL rules.

For example:

The following are URLs where a portion of the path is a user name variable that changes according to the user that logs in:

For the user Mark, the URL is /exchange/Mark/myhome
For Benjamin, the URL is /exchange/Benjamin/myhome
And for Sean, the URL is /exchange/Sean/myhome

If you wish to represent the user name with the “symbol” <UserName>, for example, create a rule with the following URL:

/exchange/<UserName >/myhome

For portal trunks, the configuration is per-application; if you use URL variables in multiple applications, repeat this procedure for each application.

For Web mail or basic trunks, the configuration is per-trunk; if you use URL variables in multiple trunks, repeat this procedure for each trunk.

Configuring the use of URL variables in the authentication pages

This section describes how you configure the authentication pages to include both the “symbol” parameter and the parameter value. The configuration is per-trunk; if you use URL variables in multiple trunks, repeat the procedure described here for each trunk.

To configure user variables in the authentication pages

Access the following custom folder:

…\Whale-Com\e-Gap\von\InternalSite\inc\CustomUpdate

If this folder does not exist, create it.
Under the customUpdate folder, create the following inc “hook”, which will be activated before the PostValidate.asp reaches the client side:

PostPostValidate.inc

Name the file as follows:

Trunk_Name <Secure(0=no/1=yes)>PostPostValidate.inc

For example:

For an HTTPS trunk named “WhaleSite”, create the file:

WhaleSite1PostPostValidate.inc

Tip

If a file by this name already exists, you can use the existing file; you do not need to create a new file in this case.
In the hook file you created in step 2, add the following lines:

<%

SetSessionResourceParam g_cookie, <Application _ID>, “ParamName”, "Parameter_Symbol"

SetSessionResourceParam g_cookie, <Application_ID>, “ParamVal”, “Parameter_Value”

%>

For example:

<%

SetSessionResourceParam g_cookie, <Application_ID>, “ParamName”, "< UserName >"

SetSessionResourceParam g_cookie, <Application_ID>, “ParamVal”, Session(“ user_name1 ”)

%>

Where in this example:
- < UserName > is the “symbol” parameter you entered in the URL List, in the URL Set tab.
- Session (“user_name1”) is a dynamic representation of the lead user name entered by the user during login. The value of user_name1 changes according to the user that is logged in (for example, Mark, Benjamin, or Sean).