Brennan’s Blog

A common requirement for websites is to allow users to log into multiple websites once and then access each site transparently. The term used for this scenario is Single Sign-On (SSO). A great deal of work has gone into making such a system work. For large corporations, you may be integrating many third-party tools across the enterprise to tie together accounting, inventory and human resource applications. This has been necessary because these systems may not have been designed to work with a shared identity service and data store, such as LDAP, from the start.

One of the new additions to the ASP.NET 2.0 was the Membership and Profile system using the Provider Model. It works as a sort of plugin architecture for authentication and identity modules. One set of the default providers works with SQL Server, such as the SqlMembershipProvider. The beauty of the Provider Model is that you can build your own custom provider which conforms to the provider's design contract, or interface.

Using this provider model, it is possible to create a powerful SSO solution which works with SQL Server or even a custom implementation. And it should be noted that these providers do not have to run with an ASP.NET website. They will function in any .NET application, desktop or even console. The possibilities in this space are unlimited.

To implement authentication across multiple websites you need to get the HTTP Cookie used as the authentication token to work across each of the websites. For privacy and security reasons, a cookie cannot simply be passed around to multiple websites. It has to share a common root domain. This requirement is why you have seen the following websites:

• www.google.com, mail.google.com, adsense.google.com, video.google.com
• www.yahoo.com, my.yahoo.com, mail.yahoo.com, movies.yahoo.com
• www.live.com, spaces.live.com, offwhite2006.spaces.live.com
• abcnews.go.com, espn.go.com, disney.go.com, movies.go.com

In the case of the Go.com domains, the partnership created to produce the Go.com portal has long since ended but each site still maintains their own separate sites under this domain structure. The www domain now acts as a simple gateway to each of the websites instead of the content-oriented portal it once was.

To run multiple ASP.NET 2.0 websites with a common authentication backend this cookie requirement still applies, however, it is easy to set up. For starters you can configure the cookie domain for the website with the httpCookies element in the web.config. Assuming you have each of your sites rooted in the same base domain you should be able to use that as your root domain. In the case of my websites, I would use offwhite.net.

Next you would configure your Membership, Roles and Profile providers to use a common backend across each website. Assuming you are using the SQL Server implementations, you can point them to the same database. With this configuration you can even host your websites across many different servers as long as they all still talk to the same database. However, there may be little more which needs to be done. To get the authentication tokens to work properly across many websites you must configure your machine keys with the machineKey element in the web.config. Normally the machine key is generated automatically for the machine, but doing so across multiple websites and servers would break our multi-site solution.

I have put together a working example with 3 websites: site 1, site 2 and site 3. Each site is colored with an exciting different shade of gray as a visual cue that you are on a different website. As you see from the web.config (see below), it is configured with the same SQL Server provider implementations. This configuration is identical across all 3 websites. It demonstrates that accounts are truly running across each of the websites.

As you click the link to the protected page it will deny you access and give you the option to log in or create a new account. Go ahead and create an account to try out the protected page. On the protected page you can set a value for the Session and one for the Profile. Since the Profile is configured to use the SqlMembershipProvider it works across multiple websites while the sessions do not.

Surprisingly enough, I was able to get this example set of sites up and running in under an hour. Most of it was done with the Login controls which are a part of ASP.NET 2.0 which cut down on the work necessary. The rest was just configuration for the providers. An SSO solution in under an hour sounds pretty good to me.

[ Download Project ]

Web.config

<?xml version="1.0"?>
<configuration>
  <appSettings/>
  <connectionStrings>
    <add name="ConnectionString1" connectionString="Data Source=(local);
  Initial Catalog=MultipleSiteAuthentication;Integrated Security=true"
         providerName="System.Data.SqlClient"/>
  </connectionStrings>
  <system.web>
    <compilation debug="true" />
    <httpCookies domain="offwhite.net" requireSSL="false" />
    <authentication mode="Forms">
      <forms loginUrl="Login.aspx" name=".ASPXFORMSAUTH"/>
    </authentication>
    <anonymousIdentification enabled="true"/>

    <machineKey
      validation="SHA1"
      validationKey="B03F5F7F11D50A3AB03F5F7F11D50A3A123F5F7F11D50A3AB03F5F7F11D50A3C,IsolateApps"
      decryptionKey="B03F5F7F11D50A3AB03F5F7F11D50A3A123F5F7F11D50A3AB03F5F7F11D50A3C,IsolateApps" />

    <roleManager defaultProvider="AspNetRoleProvider" enabled="true">
      <providers>
        <clear />
        <add name="AspNetRoleProvider"
            applicationName="app1"
            connectionStringName="ConnectionString1"
            type="System.Web.Security.SqlRoleProvider" />
      </providers>
    </roleManager>

    <membership defaultProvider="AspNetSqlMembershipProvider">
      <providers>
        <clear/>
        <add name="AspNetSqlMembershipProvider"
            applicationName="app1"
            connectionStringName="ConnectionString1"
            enablePasswordRetrieval="false"
            enablePasswordReset="true"
            requiresUniqueEmail="true"
            passwordFormat="Clear"
            passwordStrengthRegularExpression=""
            minRequiredPasswordLength="1"
            minRequiredNonalphanumericCharacters="0"
            type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0,
  Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </providers>
    </membership>

    <profile defaultProvider="AspNetSqlProfileProvider" automaticSaveEnabled="true">
      <providers>
        <clear/>
        <add
          applicationName="app1"
          name="AspNetSqlProfileProvider"
          connectionStringName="ConnectionString1"
          description=""
          type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.0.0,
  Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </providers>
      <properties>
        <add name="ProfileValue" type="String"  allowAnonymous="false" />
      </properties>
    </profile>

  </system.web>
  <location path="Admin">
    <system.web>
      <authorization>
        <allow roles="Admin"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>
  <location path="Protected">
    <system.web>
      <authorization>
        <deny users="?"/>
      </authorization>
    </system.web>
  </location>
</configuration>