Larry Steinle

Web sites are usually created for an intranet user or an internet user. This article explains how to create a single site for both intranet and internet usage while retaining the benefit of single sign-on for internal connections without compromising the security of external connections.

Background

When developing a web site for internal, intranet usage developers prefer to use Windows Authentication Security Mode. Users prefer Windows Authentication because they don’t have to log into the web site. The Windows Authenticated web site automatically knows who the user is and what rights the user has to the system.

However, Windows Authentication does not work externally on the internet. For external, internet connections a developer may choose to use Forms Authentication. Forms Authentication requires the user to provide credentials (usually in the form of a user name and password) to prove to the system they have rights to the web application.

What should you do when you want a web site to support both Windows and Forms Authentication at the same time? Can you create a web site that allows both the convenience of automatic sign-on from an internal connection and secure sign-on authentication from an external connection? Yes!

Two Sites for Mixed Mode Authentication

One popular strategy for supporting Mixed Mode or Single Sign-on Security (SSO) is to create two sites: one site configured with Windows Authentication and another site with Forms Authentication. When the user fails the Windows Authentication request configure IIS to redirect the user to the Forms Authenticated site. When the user passes the Windows Authentication request create a Forms Ticket (using the same cipher key as the Forms Authentication site) and redirect the user to the Forms Authentication site.

Two Sites Emulating Mixed Mode Authentication Process Flow

What if you don’t want two sites to support Mixed Mode Authentication?

Such was the challenge I recently encountered. In my search on this very problem I discovered an article from Microsoft written in 2004, Mixing Forms and Windows Security in ASP.Net. I realized it could be done. Unfortunately the article’s instructions were designed for an older version of IIS and involved more configuration changes to IIS than I wanted to make. Further searches revealed there weren’t any articles that pulled all the pieces together for the current VS.Net framework.

This article pulls all the information from my research together into a single resource. You will learn how IIS and various browsers behave when authenticating a user, how to configure a web site for both internal and external use and how to configure your web application to support mixed mode authentication. The code has been tested on both an internal and external connection using Internet Explorer, Safari for Windows, Google Chrome, Mozilla Firefox and Opera browsers.

Browser and IIS Authentication

The IIS Authentication options controls how the site manages security. Anonymous Authentication or Windows Authentication must be enabled. Anonymous Authentication basically disables security. However, when used with Forms Authentication it allows the developer to control which parts of the site have anonymous (or open) access and which parts require a forms authentication ticket with role based permissions for access. At least the login page must be configured for anonymous users otherwise the user can never access the login page to identify themselves.

Windows Authentication requires the computer to be on the same domain as the server. The browser will forward the NTLM or Kerberos data with the request to the server. This information provides proof of identify allowing the programmer to control access using role based permissions.

Unlike Forms Authentication, Anonymous Authentication can’t be used with Windows Authentication. When Anonymous Authentication is used the NTLM/Kerberos data is lost. However, Forms Authentication can be used with Windows Authentication.

ASP.Net Process Flow Differences

It is important to recognize that ASP.Net follows a slightly different process with Forms Authentication and Windows Authentication. The following two diagrams show the process flow from page request to page response for the different security models.

In Forms Authentication IIS validates the identify of the user after calling the IHttpModule.OnAuthenticateRequest and before calling the IHttpModule.OnAuthorizeRequest. If the user has no Forms Authentication Ticket then the server returns a 302 response to the browser redirecting the user to the forms login page.

Forms Authentication Process Flow

On the other hand, with Windows Authentication IIS validates the identity of the user before calling the IHttpModule.OnAuthenticateRequest. If the user can’t be identified then a 401 challenge response is returned to the browser.

Windows Authentication Process Flow

Mixed Authentication Strategy

Technically our site is going to be a Forms Authentication site with Windows Authentication enabled to identify the internal user. The site will continue to follow a similar process as the two site example described earlier in this post.

When a user on the intranet browsers to the site we will want to intercept the user credentials from the Windows Authentication logic creating a Forms Authentication Ticket which will provide common access to the site. Without the Forms Authentication ticket the user will be redirected to the login page even though the Windows Authentication passed.

When a user requests a page from the internet and they have no Forms Authentication Ticket we will create an Anonymous Ticket that gives the user access just to the login page. Without the Anonymous Ticket the Windows Authentication would throw an error and the user wouldn’t be able to reach the login page. When Forms Authentication passes then Windows Authentication is ignored. The Anonymous Ticket is used in place of the Anonymous Authentication behavior.

A few things we need to understand for this logic to work correctly:

• When is the user navigating to the site from an internal network connection or an external internet connection? Windows Authentication should be guaranteed to work only from internal connections.
• When is Forms Authentication and Windows Authentication enabled on the site? Ideally we want to disable creating a Forms Ticket when only Windows Authentication is enabled in IIS. And, there is no need to perform Windows Authentication checks when only Forms Authentication is enabled.
• Does the requesting browser support Windows Authentication?

This logic will be implemented in a module so that we can easily add the mixed authentication support to any web site.

Creating and Configuring a Web Site for Mixed-mode Authentication

To support both Forms and Windows Authentication on the same site configure IIS with both Windows Authentication enabled and Forms Authentication enabled. If your browser has problems authenticating you may need to modify the order the providers are listed for the Windows Authentication option as some browsers do not support the Negotiate model.

Coding a Web Application to Support Mixed-mode Authentication

The code in this article has been tested with all major browsers. Safari for Windows does not support Windows Authentication. However, the system can be coded so that it automatically detects the Safari browser forcing the user into the external internet Forms Authentication logic flow.

For the code in this article to work you will need to include the code from two earlier posts:

• Web Information post, and
• Big Brother, Little Brother or No Bother? article to distinguish between internal and external connections.

MixedAuthenticationModule

This section creates a module to intercept events and call the mixed mode authentication logic. The module guarantees that only authenticated users are permitted to continue to the requested page otherwise it redirects the user to the login page.

using System;
using System.Web;

namespace MixedAuth
{
    public class MixedAuthenticationModule : IHttpModule
    {
        public void Dispose() { }

        public void Init(HttpApplication context)
        {
            context.AuthenticateRequest += new EventHandler(OnAuthenticateRequest);
            context.AuthorizeRequest += new EventHandler(OnAuthorizeRequest);
            context.EndRequest += new EventHandler(OnEndRequest);
        }

        public void OnAuthenticateRequest(Object source, EventArgs e)
        {
            //The AuthenticateRequest event fires after windows authentication and
            //before forms authentication. Here we need to ensure that everything
            //is configured correctly so the system won't throw a 302 error when
            //we are on the log-in page.
            MixedAuthentication.EnforceMixedMode();
        }

        public void OnAuthorizeRequest(Object source, EventArgs e)
        {
            //Ensure that only unauthorized users (anonymous users) are required
            //to log-in and authenticate with the system before giving them access
            //to the web site.
            MixedAuthentication.RedirectToLoginWhenUnauthorized();

            //When forms authentication is enabled even a 401 windows challenge
            //is redirected to the log-in page. Detect when we are being directed
            //to the log-in page even after successfully authenticating the user
            //returning the user to the originally requested page.
            MixedAuthentication.RedirectFromLoginWhenAuthorized();
        }

        public void OnEndRequest(Object source, EventArgs e)
        {
            //This is the only opportunity to intercept a windows challenge response
            //and over-ride it to permit the user access to the form's log-in page.
            if (WebInfo.IsWindowsChallenge && !WebInfo.IsWindowsModeSupported)
                MixedAuthentication.RedirectToLoginPage();
        }
    }
}

MixedAuthentication

This is the heart of the mixed authentication logic. The code handles redirecting unauthenticated users to the login page permitting authenticated users to continue to the requested page.

using System;
using System.Web;
using System.Web.Security;
using System.Security.Principal;

namespace MixedAuth
{
    /// <summary>
    /// Manages mixed-authentication services for Web applications. This class cannot be inherited.
    /// </summary>
    public sealed class MixedAuthentication
    {
        private const string ANONYMOUS_USER_NAME = "Anonymous";

        /// <summary>
        /// Sets the current security context to an anonymous user and adding it to the 
        /// cookies collection of the response, or to the URL if you are using cookieless
        /// authentication.
        /// </summary>
        public static void SetAnonymous()
        { AuthorizeUser(ANONYMOUS_USER_NAME); }

        /// <summary>
        /// Sets the current security context to the specified user name and adds it to the
        /// cookies collection of the response, or to the URL if you are using cookieless
        /// authentication.
        /// </summary>
        /// <param name="userName">
        /// The name of an authenticated user. This does not have to map to a Windows account.
        /// </param>
        public static void AuthorizeUser(string userName)
        {
            if (userName != WebInfo.UserName)
            {
                //Forms Authentication Uses GenericPrincipal
                //Windows Authentication Uses WindowsPrincipal
                GenericIdentity identity = new GenericIdentity(userName, "Custom");
                WebInfo.User = new GenericPrincipal(identity, null);
            }
            FormsAuthentication.SetAuthCookie(userName, false);
        }

        /// <summary>
        /// Get a value that indicates when the current user is an anonymous user.
        /// </summary>
        public static bool IsAnonymousUser
        {
            get { return WebInfo.UserName == ANONYMOUS_USER_NAME; }
        }

        /// <summary>
        /// Get a value that indicates when the user is authenticated.
        /// </summary>
        /// <remarks>
        /// This method can return false while the WebInfo.IsAuthorized
        /// returns true. WebInfo.IsAuthorized treats Anonymous users as
        /// authorized users where this one does not because a ticket
        /// must be created to ensure the user can access the log-in page
        /// when both forms and windows mode authentication is enabled.
        /// </remarks>
        public static bool IsAuthorized
        {
            get { return WebInfo.IsAuthenticated &amp;amp;amp;&amp;amp;amp; !IsAnonymousUser; }
        }

        /// <summary>
        /// Get a value that indicates when the user is requesting the log-in page.
        /// </summary>
        public static bool IsLoginPageRequest
        {
            get { return WebInfo.Request.RawUrl.ToLower().StartsWith(FormsAuthentication.LoginUrl.ToLower()); }
        }

        /// <summary>
        /// Get the originally requested URL.
        /// </summary>
        /// <remarks>
        /// Return URL is available only from the log-in page after the user is authorized.
        /// </remarks>
        public static string ReturnUrl
        {
            get
            {
                if (!IsLoginPageRequest || !IsAuthorized) return string.Empty;
                return !string.IsNullOrEmpty(WebInfo.QueryString["ReturnUrl"]) ? WebInfo.QueryString["ReturnUrl"] : FormsAuthentication.DefaultUrl;
            }
        }

        /// <summary>
        /// Redirects the authorized user back to the originally requested URL or the default URL.
        /// </summary>
        public static void RedirectFromLoginPage()
        {
            if (IsAuthorized) WebInfo.Response.Redirect(ReturnUrl);
        }

        /// <summary>
        /// Authorizes the specified user redirecting them back to the originally requested URL or the default URL.
        /// </summary>
        /// <param name="userName">
        /// The authenticated user name.
        /// </param>
        public static void RedirectFromLoginPage(string userName)
        {
            AuthorizeUser(userName);
            if (IsAuthorized) WebInfo.Response.Redirect(ReturnUrl);
        }

        /// <summary>
        /// Redirects an authenticated user back to the originally requested URL or the default 
        /// URL when the user is requesting the log-in page and authorized to use the site.
        /// </summary>
        public static void RedirectFromLoginPageWhenAuthorized()
        {
            if (IsLoginPageRequest &amp;amp;amp;&amp;amp;amp; WebInfo.IsFormsModeEnabled &amp;amp;amp;&amp;amp;amp; WebInfo.IsWindowsModeEnabled)
                RedirectFromLoginPage();
        }

        /// <summary>
        /// Redirects the browser to the log-in URL when the user is not authorized.
        /// </summary>
        public static void RedirectToLoginPageWhenUnauthorized()
        {
            if (!IsAuthorized &amp;amp;amp;&amp;amp;amp; !IsLoginPageRequest &amp;amp;amp;&amp;amp;amp; (WebInfo.IsFormsModeEnabled || WebInfo.IsWindowsModeEnabled)) RedirectToLoginPage();
        }

        /// <summary>
        /// Redirects the browser to the log-in URL setting the current user to anonymous.
        /// </summary>
        public static void RedirectToLoginPage()
        {
            MixedAuthentication.SetAnonymous();
            if (IsLoginPageRequest &amp;amp;amp;&amp;amp;amp; WebInfo.ResponseStatusCode == 302) return;
            WebInfo.ResponseStatusCode = 302;
            WebInfo.Response.Redirect(FormsAuthentication.LoginUrl);
        }

        /// <summary>
        /// Ensures that Windows Authentication is working correctly when running in Mixed Mode.
        /// </summary>
        /// <remarks>
        /// When running in Windows Mode only or when compiled with CLR 4.0 or greater this code is not required.
        /// </remarks>
        public static void EnforceWindowsMode()
        {
            if (WebInfo.IsWindowsModeSupported &amp;amp;amp;&amp;amp;amp; WebInfo.IsWindowsModeEnabled &amp;amp;amp;&amp;amp;amp; !WebInfo.InSecurityContext &amp;amp;amp;&amp;amp;amp; WebInfo.LogonUser.Length > 0)
                AuthorizeUser(WebInfo.LogonUser);
        }

        /// <summary>
        /// Ensures that forms authentication overrides windows authentication when there are conflicts.
        /// </summary>
        public static void EnforceFormsMode()
        {
            if (!WebInfo.IsFormsModeEnabled) return;

            HttpCookie authCookie = null;
            FormsAuthenticationTicket ticket = null;
            if (WebInfo.InWebContext)
                if (WebInfo.Request.Cookies.Count > 0)
                {
                    //Ensure that we didn't override Windows Authentication (impersonation or login as another user)
                    authCookie = WebInfo.Request.Cookies[FormsAuthentication.FormsCookieName];
                    try
                    {
                        if (authCookie != null || authCookie.Value != null)
                            ticket = FormsAuthentication.Decrypt(authCookie.Value);

                        if (ticket.Name != WebInfo.UserName)
                            MixedAuthentication.AuthorizeUser(ticket.Name);
                    }
                    catch
                    {
                        //If we can't decrypt the cookie it is because we never created the 
                        //cookie to begin with. This can occur when Anonymous Authentication
                        //is enabled and Forms Authentication is disabled.
                    }
                }
                else
                {
                    //Ensure that the forms ticket is created for the current security context.
                    //Failure to perform this check may cause unending loops with browsers like
                    //Chrome, Safari and Mozilla as the log-in page will throw an error because
                    //there isn't even an anonymous user ticket assigned.
                    if (WebInfo.InSecurityContext)
                        AuthorizeUser(WebInfo.UserName);
                    else if (!WebInfo.IsWindowsModeEnabled)
                        AuthorizeUser(ANONYMOUS_USER_NAME);
                }
        }

        /// <summary>
        /// Ensures that Forms and Windows Authentication are correctly applied.
        /// </summary>
        public static void EnforceMixedMode()
        {
            EnforceWindowsMode();
            EnforceFormsMode();
        }
    }
}

Web.Config

Be careful to set the options as shown below in the web.config so that IIS is configured correctly and to enable the mixed authentication module.

<?xml version="1.0"?>
<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="Login.aspx"/>
    </authentication>
  </system.web>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true">
      <add name="MixedAuthenticationModule" type="TestAuth.MixedAuthenticationModule"/>
    </modules>
  </system.webServer>
</configuration>

Default.aspx

This page will display security context information about the user so you can see how the different authentication methods affects the type of user created for the site.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="MixedAuth.Default" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head runat="server">
    <title></title>
  </head>
  <body>
    <form id="form1" runat="server">
      <p>
        <asp:Literal ID="UserName" runat="server" />
      </p>
      <asp:Button ID="LogOff" runat="server" OnClick="LogOff_Click" Text="Log Off" />
    </form>
  </body>
</html>

using System;
using System.Threading;
using System.Web;
using System.Web.Security;

namespace MixedAuth
{
    public partial class Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            UserName.Text = string.Empty;
            UserName.Text += "<br/>Raw Url = " + Request.RawUrl;
            UserName.Text += "<br/>Login Url = " + FormsAuthentication.LoginUrl;
            UserName.Text += "<br/>Logon User = " + Request.ServerVariables["LOGON_USER"];
            UserName.Text += "<br/>Auth User = " + Request.ServerVariables["AUTH_USER"];
            UserName.Text += "<br/>Remote User = " + Request.ServerVariables["REMOTE_USER"];
            UserName.Text += "<br/>Unmapped Remote User = " + Request.ServerVariables["UNMAPPED_REMOTE_USER"];
            UserName.Text += "<br/>User Identity = " + User.Identity.Name;
            UserName.Text += "<br/>Thread Identity = " + Thread.CurrentPrincipal.Identity.Name;
            UserName.Text += "<br/>Is Authenticated = " + User.Identity.IsAuthenticated;
            UserName.Text += "<br/>Authentication Type = " + User.Identity.AuthenticationType;
            UserName.Text += "<br/>Principal Type = " + User.GetType().FullName;
            UserName.Text += "<br/>Forms Mode Enabled = " + WebInfo.IsFormsModeEnabled;
            UserName.Text += "<br/>Windows Mode Enabled = " + WebInfo.IsWindowsModeEnabled;
            UserName.Text += "<br/>Windows Mode Supported = " + WebInfo.IsWindowsModeSupported;

            if (Request.ServerVariables["LOGON_USER"] != User.Identity.Name)
                UserName.Text += @"<p styl='margin-left:25%;margin-right:25%;'>
  Notice that Logon User contains a different name from the other user name properties. 
  This is because Logon User retains the original NTLM account name for the client while 
  the other user fields store the user account from the authentication filter (in this 
  case the forms ticket). This can be useful when you need to track when a user is logged 
  into the web site from another user's machine.
</p>";
        }

        protected void LogOff_Click(object sender, EventArgs e)
        {
            MixedAuthentication.RedirectToLoginPage();
        }
    }
}

Login.aspx

Of course we need a login page for the external internet users and for internal users who need to login from another users computer.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Login.aspx.cs" Inherits="MixedAuth.Login" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
  <head runat="server">
    <title>User Login</title>
  </head>
  <body>
    <form id="form1" runat="server">
      <table>
        <tr>
          <th>User Name:</th>
          <td>
            <asp:TextBox ID="UserName" runat="server" />
          </td>
        </tr>
        <tr>
          <th>Password:</th>
          <td>
            <asp:TextBox ID="Password" runat="server" TextMode="Password" />
          </td>
        </tr>
        <tr>
          <td colspan="2" style="text-align:right;">
            <asp:Button ID="AuthenticateUser" runat="server" Text="Login" OnClick="AuthenticateUser_Click" />
          </td>
        </tr>
      </table>
      <asp:Literal ID="UserInfo" runat="server" />
    </form>
  </body>
</html>

using System;

namespace MixedAuth
{
    public partial class Login : System.Web.UI.Page
    {
        protected void AuthenticateUser_Click(object sender, EventArgs e)
        {
            if (CredentialsAreValid(UserName.Text, Password.Text))
                MixedAuthentication.RedirectFromLoginPage(UserName.Text);
        }

        private bool CredentialsAreValid(string userName, string password)
        {
            //YOUR CODE GOES HERE OR USE A MembershipProvider
            return true;
        }
    }
}

Mozilla Windows Authentication Support

Out of the box Mozilla does not support Windows Authentication. An add-in has been created for Mozilla that simplifies configuring Mozilla for Windows Authentication. Simply download and install the Integrated Authentication for Firefox extension and follow the directions to configure the browser for your local environment.

Summary

Now you should understand the behavior differences between Forms and Windows Authentication, and learned how to support mixed authentication in your ASP.Net web sites!

Happy coding!