Seamless sign on to internal web applications using your Windows credentials

I was recently tasked to architect and lead the Single Sign On (SSO) implementation within the Pan Asia region. This is part of the global identity management initiative whose vision is enable any employee in any part of the world to access any authorized internal application, be it web or desktop, using a single username and password.

Given that:

1. the scope is for internal systems only,
2. all workstations are part of an Active Directory domain,
3. Windows authentication (aka NTLM/Kerberos) is the standard authentication protocol for non-web related access (shared folders, printers, Microsoft Exchange, etc) in our environment,
4. Internet Explorer is the standard browser application used in our environment.

Its a no-brainer that the cheapest and quickest way to achieve SSO is by enabling Windows authentication on the web application end.

Besides cost savings, the other major benefit to this approach is that users only have to sign on to their workstations once (i.e. the normal Windows login process) and enjoy seamless access to any (internal) web applications just like how you access Microsoft Outlook or shared folders today.

Getting this up and running in ASP/IIS based web applications is a piece of cake. See recipe. (No pun intended.) The key steps are:

1. Disable Anonymous Access and enable "Integrated Windows authentication" in IIS for the ASP/ASPX application in question.
2. Do the same in the web config file if this is an ASP.NET application.
3. In your code, grab the id of the user using the code Request.ServerVariables["LOGON_USER"].

On the Java front, there are two choices mainly:

1. via a servlet filter like JCIFS NTLM HTTP Authentication module, or
2. via Andy Armstrong's JAAS login module

One gotcha to take note of. The above works when your application, hosted in the internal network is accessed from the web browser:

1. via an internal IP.
2. via the hostname of the IIS server.
3. via a fully qualified domain name (FQDN) that is a sub-domain under your Windows domain. i.e. your Windows domain is acme.com and your application domain name is abc.acme.com.

If, however, your application is accessed via a FQDN other than the above, you will find that user is prompted for his credentials in a popup dialog much like what you get in Basic Authentication. Details on this issue (and workarounds) can be found in this KB article (ID 303650).

In summary, its due to Internet Explorer mistakenly identified your site as an Internet site and the default browser settings prevents it from sending your Windows credentials for security reasons. To overcome this, you have to add the FQDN to the "Trusted sites" or "Local Intranet" lists.

To make life easier for your users, and since they are all on the domain, you can get your system administrators to push this configuration change to their PCs transparently via group policies or logon scripts.