Ben Ari's UAG and IAG Blog

Plenty of useful and fun info on UAG, Microsoft's remote access and reverse-proxy product.

Custom Form Login SSO how-to

Custom Form Login SSO how-to

  • Comments 4
  • Likes

One of the most important abilities of IAG is the single sign on, which lets connecting users access to internal applications without having to re-type their username and password. IAG contains multiple SSO mechanisms, but on some occasions, one might be required to create a custom one. The process of creating a custom login is thoroughly documented in Appendix C of the advanced user guide (Page 381), as well as here (, but here’s a summary of this procedure that should be easier to follow for creating simple customizations.

The 1st step is to gather some details about the application. The details are:

1. Application Type. This parameter was selected when the application was initially published on IAG. To find it, look at the list of applications on the portal, and check what appears in “application type”


2. The internal URL of the login page.

3. The name of the username and password fields in the HTML form. For example:

<form id="quick" method="get" action="/dosearch.action">


<legend>Quick Search</legend>

<input id="quick-search-query" type="text" accessKey="q" autocomplete="off" name="queryString" size="25"/>

<div class="form-block"><p><div class="steplabel" style="width: 150px;"><u>U</u>sername: </div>

<input type="text" name="uname" tabindex="1" accesskey="U" size="30"><br/></p>

<p><div class="steplabel" style="width: 150px;"><u>P</u>assword: </div>

<input type="password" name="pword" tabindex="2" accesskey="P" size="30">


Using these details, a custom XML file needs to be created, and placed on the server. The syntax of the file is this:




<USAGE description="form_login">


<SCRIPT_NAME source="data_definition">WhaleSubmitStandard</SCRIPT_NAME>


<AGENT_TYPE search="group">all_supported</AGENT_TYPE>


<SCRIPT_NAME source="data_definition">WhaleHandler</SCRIPT_NAME>






<CONTROL handling="dummy_value">


<NAME>Username field name from step 3</NAME>



<CONTROL handling="dummy_value">


<NAME> Password field name from step 3</NAME>







When filling the URL portion, keep in mind that IAG uses RegEx to match URLs, so it would generally be a good idea to feed in a general mask, with RegEx parameters. For example, the URL http://crmserver/userenv/login.asp should be input as .*userenv/login\.asp

In the above example, we substitute .* for the server name, as “.*” in RegEx means “everything and anything”. Later, we slash-out the dot before asp, because a dot is an operator in RegEx.

Another thing to take into account is the Multiple Login parameter. In the above example, I’ve set it to TRUE, which means that the form will be submitted anytime the user goes to the same page. The purpose of this is to meet situations in which a user logs out of the application, goes back to the IAG portal, and then re-launches the application. Setting the value to FALSE would not re-submit the form. Setting it to TRUE is usually a good idea, although in some cases, an application uses the same URL for multiple functions, and then setting the multiple login to true would cause IAG to try to re-submit the page every time.

Once the data has been filled out, save the file under the folder c:\whale-com\e-Gap\von\conf\wizarddefaults\FormLogin and name the file FormLogin.xml. Activate the IAG configuration, checking the option to apply changes made to external configuration files. This is all it takes!

  • Any updates to this with the release of Update 2?  Having some trouble configuring this so it passes the credentials through to  a Siteminder portal page.  Thanks for your contributions to the community btw!  :)

  • Update 2 does not affect this. It can be challanging to work out, so you are more than welcome to post about this in the public forum, where I, or one of our MVPs, will be glad to help!

  • Instead of replacing the formlogin.xml file with the custom version in C:\whale-com\e-Gap\von\conf\wizarddefaults\FormLogin\, you meant that we should place it in a CustomUpdate folder, right? As in:


  • Response to Dennis - you are correct. I will ammend the text ASAP. Thanks for pointing this out!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment