none
LoginForm.xml or how to configure SSO to web apps RRS feed

  • Question

  • Recently I've managed to install UAG and configure access to portal (HTTPS) that has one web application. The next step that I want to do is set up SSO to backend web app. I read a few articles and technet documentation. All of them told that I need to create own FormLogin.xml under CustomUpdate folder. I did as it was described but can't achieve SSO funcionality working :( Here is the steps that I did:

    1. Created web app and tick "Enable SSO" on authentication tab and selected LoginForm radiobutton. Set authentication repository (same AD server as one that used for portal authentication)

    2. Created LoginForm.xml and put it under CustomUpdate folder.

    <WHLFILTFORMLOGIN ver="1.0">
    <APPLICATION>
    <APPLICATION_TYPE><strong>Web</strong></APPLICATION_TYPE>
    <USAGE description="form_login">
    <PRIMARY_HOST_URL>*Login*</PRIMARY_HOST_URL>
    <SCRIPT_NAME source="data_definition">FormLoginSubmitStandard</SCRIPT_NAME> 
    <USER_AGENT>
    <AGENT_TYPE search="group">all_supported</AGENT_TYPE>
    <POLICY>multiplatform</POLICY>
    <SCRIPT_NAME source="data_definition">FormLoginHandler</SCRIPT_NAME> 
    </USER_AGENT>
    <MULTIPLE_LOGIN>true</MULTIPLE_LOGIN>
    <LOGIN_FORM>
    <NAME>theLoginForm</NAME>
    <METHOD>POST</METHOD>
    <CONTROL handling="dummy_value">
    <TYPE>USER_NAME</TYPE>
    <NAME>uname</NAME>
    <DEF_VALUE>whaleusr</DEF_VALUE>
    </CONTROL>
    <CONTROL handling="dummy_value">
    <TYPE>PASSWORD</TYPE>
    <NAME>pword</NAME>
    <DEF_VALUE>whlpass</DEF_VALUE>
    </CONTROL>
    </LOGIN_FORM>
    </USAGE>
    </APPLICATION>
    </WHLFILTFORMLOGIN>
    
    

    and here is a full URL to application http://myserver/scripts/ttcgi.exe?command=LoginScreen

    What am I doing wrong?

    Thanks

    Thursday, May 20, 2010 2:32 AM

Answers

  • No, this is happening every time you click the link of this application.

     

    Just that when it is not configured to open in a new window, you do not see the application address in the browser address bar. What you see there () is the address of the portal home page, which is a frame set, and that frame set (and its address) does not change when apps are opened in one of the frames. But in any case, the request sent by the browser is still http://myserver/...

    • Marked as answer by Erez Benari Thursday, June 17, 2010 6:19 PM
    Wednesday, May 26, 2010 7:46 PM

All replies

  • The steps you have pasted (modifying the loginform.xml, etc.) are for a custom form-based login. But the app URL doesn't look like a form-based AuthN. :-)

    So, could you please elaborate on the backed application, especially about it's authentication types/method?

    Thursday, May 20, 2010 9:23 AM
  • Yep, I'm implementing custom form-based SSO because I have my own web app. Wy doesn't it looks like form login? here is a source code of that page:

     <form action="/scripts/ttcgi.exe" method="post" name="theLoginForm">
      <input type="hidden" name="Command" value="Login">
      <input type="hidden" name="ServerName" value="">
      <input type="hidden" name="databaseid" value="0">
      <input name="uname" class="bodytext" type="text" size="24" maxlength="32">
      <input name="pword" class="bodytext" type="password" size="24" maxlength="32">
      <input type="image" src="/ttweb/images/btn_login_e.gif" alt="Login to TestTrack Web" name="OkBtn" border="0">
    </form>
    Thursday, May 20, 2010 12:24 PM
  • Hi Vetas,

    Please check out the UAG Regex++ syntax reference here: http://technet.microsoft.com/en-us/library/dd282903.aspx, where you can see the '*' character is a repeat, but in Regex++ you need to specify which character it should repeat (for example, any character, which is represented by a dot character '.'). So you're URL could look something like: /.*Login.*

    Please also note that the <PRIMARY_HOST_URL> in FormLogin.xml should contain a Regex++ expression that matches the URL which, when received by the backend application, causes the application to send back the form. In your example above, it looks to me that the URL you mentioned - /scripts/ttcgi.exe?command=LoginScreen - is the URL that is sent by the form itself, when the form is submitted, in other words the “action” of the form.

    Thursday, May 20, 2010 5:44 PM
  • Ran,

    Yes, this is my login URL, not action. I modified the primary host url like you said "/.*Login.*" or ".*Login.*" but nothing worked :( I tried with another app http://myserver:8080/sites/test/LoginTest.html, in the HOST URL I typed "/.*DemoTest.*"  or ".*DemoTest\.html.*" also tried it within <[!CDATA]>. Also I ticked/unticked "enable sso for app" on the authentication tab (AD repository was selected). By the way does it have to be enabled? And do I need some custom repository for it?

    So I still can't get SSO working, any thoughts? And also does anyone know how to debug it?

    Friday, May 21, 2010 1:41 PM
  • Vetas,

     

    Here are a few pointers to things to verify:

    1.     Make sure your custom FormLogin.xml is placed in the correct folder: …\WizardDefaults\FormLogin\CustomUpdate

    2.     Make sure that the XML syntax of your custom FormLogin.xml is correct. It seems to be correct, based on the stuff you posted already, but it’s worth a check. Double-click the file and see if it opens in IE, or if IE complains about any syntax errors

    3.     Make sure you entered the correct application type (note: app type, not app name) in your custom FormLogin.xml. Judging from the FormLogin.xml you shared with us above, this seems to be "Web". Is this really the type you assigned to your Other Web Applicaiton? Note this is, IIRC, case sensitive. If the app type matches, after UAG Management console activation, your custom settings will be merged with default UAG FormLogin SSO settings relevant for your trunk, and they should appear in the file HTTPS_WhlFiltFormLogin.xml, which is located in the following folder: Microsoft Forefront Unified Access Gateway\von\conf\websites\<trunk_name>\conf

    4.     (We covered this already, but I’m still mentioning it here) Make sure that the URL you entered (using a regular expression) in the <PRIMARY_HOST_URL> matches the actual URL which, when sent to the backend application, returns the form

    5.     Make sure that you configured all the FormLogin.xml fields describing the form (<NAME> of the form , <METHOD>, <NAME> of the controls or fields in the form) with values that correspond to the actual HTML source of the form sent to UAG by the backend app

     

    Saturday, May 22, 2010 10:16 PM
  • Ran,

    1. Checked. Yep it is in CustomUpdate  folder and the name is LoginForm.xml
    2. Seems to be good. Checked with IE. No syntax errors.
    3. Yes, XML record appeared in HTTPS_WhlFiltFormLogin.xml
    4.
    In primary host url I tried "/.*" reg expression
    5. Seems that I specified that fields good.

    Could it due to wrong app settings? I made following configurations:
    1. Added custom web app. and conigured following parametrs:
       appname - TestApp
       apptype - Web
       adresses - myserver
       scripts - /scripts/ttcgi.exe?command=LoginScreen
       public hostname - myserver.domain.com
       authentication - myad.domain.com (Form Login selected)
       application URL - http://myserver/scripts/ttcgi.exe?command=LoginScreen
    The rest of the settigns are default. Did I miss something in that configuration?

    Monday, May 24, 2010 6:53 PM
  • Could it due to wrong app settings? I made following configurations:
    1. Added custom web app. and conigured following parametrs:
       appname - TestApp
       apptype - Web
       adresses - myserver
       scripts - /scripts/ttcgi.exe?command=LoginScreen
       public hostname - myserver.domain.com
       authentication - myad.domain.com (Form Login selected)
       application URL - http://myserver/scripts/ttcgi.exe?command=LoginScreen

    What do you mean: "scripts - /scripts/ttcgi.exe?command=LoginScreen"
    Do you mean Path?
    Monday, May 24, 2010 8:45 PM
  • Could it due to wrong app settings? I made following configurations:
    1. Added custom web app. and conigured following parametrs:
       appname - TestApp
       apptype - Web
       adresses - myserver
       scripts - /scripts/ttcgi.exe?command=LoginScreen
       public hostname - myserver.domain.com
       authentication - myad.domain.com (Form Login selected)
       application URL - http://myserver/scripts/ttcgi.exe?command=LoginScreen

    What do you mean: "scripts - /scripts/ttcgi.exe?command=LoginScreen"
    Do you mean Path?

    Sorry. Yes, paths.
    Monday, May 24, 2010 9:12 PM
  • OK, in that case much more than just FormLogin would/should not work, since the meaning of the "path" in UAG is that all URLs for this application will be found under the path (or paths) defined here.

    So, if in your case you have defined a path of /scripts/ttcgi.exe?command=LoginScreen then this tells UAG that every HTTP request for this app must start with this specific string (think of it as the prefix for all URLs). Furthermore, such a definition will also create a rule in the UAG ruleset (Advanced Trunk Configuration window -> URL Set tab -> URL list) which only allows requests that start like this. Not what you want…

     

    I recommend that:

    1.     You modify the path to a simple forward slash (you can make it more restrictive later, once you get this working, by using paths that are specific to this application, like for example /scripts/, etc.)

    2.     Then you should locate the rule in the ruleset which was automatically created for this application (its name will start with “Web_”, since it is based on the application type you have given to this app), and make sure that the Regex expression for it suits your needs. In other words, to keep it simple and get it to work, it should be /.*

    3.     Then activate

     

    Once these steps are completed the application will be configured correctly, and then you can focus on getting FormLogin to work.

     

    Regards,

    -Ran

    Tuesday, May 25, 2010 1:05 PM
  • Just modified the "paths" to "/" and also changed the rule and moved it on top of the list (Web_Rule1, URL:"/.*" Parematers: "Ignore", Methods: "POST, GET". But I still can't get SSO working :(

    BTW. I've noticed that in Activity Monitor (All events tab) I see only message that user accessed portal only. There are no records abot accessing my Web app. Could it be that all the traffic goes behind UAG and I only publish link instead of application it selfs?

    Tuesday, May 25, 2010 2:18 PM
  • I'm sorry, there's something I am probably missing: what do you see in your browser after you click on the application link within the UAG portal homepage?

    Also, since you’re saying that you might get to the application not through UAG but directly, do you have direct connectivity from your client machine to the backend web application published through UAG?

    Wednesday, May 26, 2010 9:43 AM
  • After I click on the application within portal I see app with following URL : http://trunkname.domain.com/uniquesig47e262077df1d4a1b372d12db9b3b247/uniquesig0/uagvitaliyPortalHomePage/
    But if I selected "Open in new Window" in app properties, I see that application with direct link http://myserver/scripts/ttcgi.exe?command=LoginScreen"

    All the servers (beckend web app, AD server, UAG server) are in local network and joined to same domain. And my PC (which I use to access portal) is also in same network. So I can access web app directly (without UAG).

    And what about Web Monitor, because when I published OWA (only published without SSO) i saw record that owa was accessed. But there is no such record for my test We app.

    Forgot to mention. UAG server is running within VMWare with only one network interface.

    Wednesday, May 26, 2010 11:24 AM
  • But if I selected "Open in new Window" in app properties, I see that application with direct link http://myserver/scripts/ttcgi.exe?command=LoginScreen"

    Is "myserver" the real server name? In other words, if you attempt to resolve "myserver" from the PC you are browsing from, does it resolve to the UAG external IP address (the one you have configured your UAG trunk to listen to), or does it resolve to the IP address of the backend app?
    Wednesday, May 26, 2010 1:54 PM
  • Yes it is real. And it resolves to backend app server IP address (not UAG)

    Wednesday, May 26, 2010 2:51 PM
  • Yes it is real. And it resolves to backend app server IP address (not UAG)

     

    Well Vetas, that's the issue right there!! If the browser on your client machine sends an HTTP request to http://myserver/... and "myserver" resolves to the actual application server instead of to UAG, then of course UAG is not involved in the traffic and you are completely bypassing UAG.

    I would suggest you re-organize your environment to mimic more closely a real-life environment, where the client machine does not have direct connectivity to the corporate resources (i.e. AD, OWA, SharePoint, web app, etc.) and therefore it is forced to pass through UAG in order to reach these servers and apps. This would also help you catch your configuration errors.

    -Ran

     

    Wednesday, May 26, 2010 3:17 PM
  • But this is only happening when i check "Open in a new window" option, in other case the URL is http://trunkname.domain.com/uniquesig47e262077df1d4a1b372d12db9b3b247/uniquesig0/uagvitaliyPortalHomePage/ or it doesn't matter?
    Wednesday, May 26, 2010 3:38 PM
  • No, this is happening every time you click the link of this application.

     

    Just that when it is not configured to open in a new window, you do not see the application address in the browser address bar. What you see there () is the address of the portal home page, which is a frame set, and that frame set (and its address) does not change when apps are opened in one of the frames. But in any case, the request sent by the browser is still http://myserver/...

    • Marked as answer by Erez Benari Thursday, June 17, 2010 6:19 PM
    Wednesday, May 26, 2010 7:46 PM
  • Ran,

    I was able to get SSO working for built-in profile of Exchange Server 2003 (401 authentication). I've noticed that traffic goes via UAG (I blocked direct access to exchange with firewall). How can I make same thing with my custom web app (I mean set traffic to go via UAG server)? I haven't changed anything in UAG or other servers settings (still accessing portal from internal network)

    Thursday, May 27, 2010 2:16 PM