Case of the Triple Single Sign On Sign On Sign On

A customer still in Windows XP land was also still suffering along with IE6 … and with final mitigating issues preventing upgrade out of the way – off they went, on their merry way, to the wonderful modern world of IE8 … (relatively speaking…)

With every corporate legacy web app working wonderfully… except integration with their single sign on solution – Novell SecureLogin. They had to upgrade their product to be IE8 compatible (http://www.novell.com/media/content/simplifying-sso-with-novell-securelogin-7.html)

And they did.

And it worked.

On every single web app.

Except for one single web page – where the username was “tripled” It looked something like this (but imagine it’s WinXP)

The problem was users had used single sign on for so many years they didn’t know their actual passwords.

Now there was a tendency to immediately blame IE8 as the culprit as IE8 had just been upgraded. But that’s not really fair as two products had been upgraded – IE8 & SSO.

In fact you could prove SSO caused the problem by reverting to IE6 but maintaining the new version of SSO – the triple single sign on issue still occurred.

Interestingly this issue did not occur on ANY other web page that was tested.

The SSO tool provides a wizard to setup websites – as a test I removed the username/password stored for this web page in the SSO administration tool. When browsing to the website Novell’s SSO IE Add-On correctly opened a dialog box to prompt for the web site’s credentials, to put away in the SSO database. However it didn’t only open 1 dialog box – it immediately opened 4 dialog boxes exactly over top of each other. You only knew there was four by moving them away from each other…

So I went into the HTML source of the page to look for anything suspicious. I first noticed it contained invalid HTML such as :

• align=”middle” was used, should be align=”center”
• valign=”centre” was used, should be valign=”middle”
• <tr> specifies colspan=”2″ this is invalid, only valid for <td>

However that seemed unlikely to break anything…then looking deeper I noticed the username, password and logon  button were all contained within their own <form></form>

<table> <tbody>

                  <tr>

                    <td>

                      <font color=”black”>User Name:</font>

                    </td>

                  </tr>

                  <tr>

                    <td>

                      <form onsubmit=”return verifyFieldandProceed(‘un’);” method=”post” name=”usernameForm”>

                        <input size=”40″ name=”un”>

                      </form>

                    </td>

                  </tr>

                  <tr>

                    <td>

                      <font color=”black”>Password:</font>

                    </td>

                  </tr>

                  <tr>

                    <td>

                      <form onsubmit=”return verifyFieldandProceed(‘pw’);” method=”post” name=”passwordForm”>

                        <input size=”40″ type=”password” name=”pw”>

                      </form>

                    </td>

                  </tr>

                  <tr colspan=”2″>

                    <td align=”right”>

                      <form onsubmit=”return verifyFieldandProceed(‘all’);” method=”post” name=”buttonForm”>

                        <input value=”Logon” type=”submit”>

                      </form>

                    </td>

                  </tr>

                </tbody>

            </table>

(note: in above code final <form></form> with post and hidden input fields are not shown…)

I modified the page for testing:

• ·         Consolidated all forms into a single form
• ·         Updated relevant JavaScript to use the new single form

The form now looked like this:

<form method=”post” onsubmit=”return verifyFieldandProceed(‘all’);” name=”loginForm” action=”http://localhost/userinfo/logon“ target=”_parent” id=”loginForm”>

        <table border=”0″ width=”80%”>

          <tbody>

            <tr>

              <td height=”80%” valign=”middle” align=”center”>

                <table>

                  <tbody>

                    <tr>

                      <td>

                        <font color=”black”>User Name:</font>

                      </td>

                    </tr>

                    <tr>

                      <td>

                        <input size=”40″ name=”un”>

                      </td>

                    </tr>

                    <tr>

                      <td>

                        <font color=”black”>Password:</font>

                      </td>

                    </tr>

                    <tr>

                      <td>

                        <input size=”40″ type=”password” name=”pw”>

                      </td>

                    </tr>

                    <tr>

                      <td align=”right” colspan=”2″>

                        <input value=”Logon” type=”submit”>

                      </td>

                    </tr>

                  </tbody>

                </table>

              </td>

            </tr>

           <tr>

              <td height=”15%” valign=”bottom” align=”center”>

                <table>

                  <tbody>

                    <tr>

                      <td class=”copyright” align=”center”>

                        Copyright © Oracle Corporation, 2001<br>

                        Minimum requirements: Netscape 4.06/MSIE 4.0 browser with JavaScript enabled, 800×600 display.

                      </td>

                    </tr>

                  </tbody>

                </table>

              </td>

            </tr>

          </tbody>

        </table><input type=”hidden” name=”UserName”> <input type=”hidden” name=”Password”>

      </form>

And Voila! The logon page worked. The problem was the new SSO got tricked by the multiple <form></form> tags on the logon page.

The temporary workaround was to distribute this local HTML file, until either the web app could be fixed, or Novell SSO could be updated. The local HTML file would automatically kick off the SSO process, and post credentials to the actual web server.