Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

Single sign-on across multiple applications in ASP.NET

0.00/5 (No votes)
31 Mar 2004 3  
By default, Forms authentication does not support single sing-on accross multiple applications. But is not too complicated to tweak it the appropriate way.

Introduction

I prefer to use the Forms authentication for most of my applications. And most of my projects consist of a few relatively independent parts running on subdomains of the main domain. It would be nice to have single sign-on, so if you are logged on at www.example.com, you would be recognized also at everything.example.com.

Forms authentication by default does not support this feature, but is not too complicated to tweak it the appropriate way.

Behind the Forms authentication

Technology behind the Forms authentication is simple: it would create a cookie of defined name (attribute name of forms attribute in web.config). The cookie would contain encrypted authentication data.

To protect user's privacy and for security reasons, you can only read cookies that you wrote. They're associated with server hostname by default. But the cookie standard supports making cookies accessible for entire domain in which the server lies. It means that from server1.example.com, you can work with cookies for both server1.example.com and example.com.

You can set domain-wide cookie only for second level domain, or for third level domain if second level domain contains three or less characters. It means that you cannot set cookie for domain "com" or "co.uk", but can for "example.com" or "example.co.uk".

So, only what you need is to make authentication cookies domain-wide.

Setting it up

You must setup authentication in system.web section of your web.config file as usual, for example:

<authentication mode="Forms">
  <forms name=".EXAMPLE-AUTH" loginUrl="/Login.aspx" 
               protection="All" timeout="30" path="/" />
</authentication>

As I said before, the authentication cookie is encrypted. By default, encryption key is generated automatically. But if you need more servers to cooperate, you need to have the keys same on both servers. This can be done by adding the following to system.web section of web.config:

<machineKey
  validationKey="BD52058A3DEA473EA99F29418689528A494DF2B00054BB7C" 
  decryptionKey="684FC9301F404DE1B9565E7D952005579E823307BED44885" 
/>

The values of validation and decryption key should be 16 (for DES) or 48 (for TripleDES) characters long hexadecimal numbers.

Signing on

You must modify the authentication cookie before sending it to the client, by specifying your domain name. The code can be as follows (assumes that user has been authenticated and his name is stored in string variable UserName):

Dim C As System.Web.HttpCookie = _
         System.Web.Security.FormsAuthentication.GetAuthCookie(UserName, False)
C.Domain = "example.com"
Response.AppendCookie(C)
Response.Redirect(System.Web.Security.FormsAuthentication.GetRedirectUrl(UserName, 
                                                                           False))

Signing off

Usually, there is no need to make something special to sign the user off - just call System.Web.Security.FormsAuthentication.SignOut(). But not in this case - the SignOut() method is unable to deal with domain-wide cookies.

You need to delete the cookie manually. And the only way to delete a cookie is to set its expiration date to past. You may do it using the following code:

Dim C As System.Web.HttpCookie = _
         Request.Cookies(System.Web.Security.FormsAuthentication.FormsCookieName)
C.Domain = "example.com"
C.Expires = DateTime.Now.AddDays(-1)
Response.Cookies.Add(C)

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here