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

Single Sign On Between Sub Domains: Forms Authentication

0.00/5 (No votes)
18 Aug 2011 1  
Single Sign On Between Sub Domains: Forms Authentication

Today, I am going to discuss one of the features that I was working on for the last few days and spent sleepless nights at office and home as well. Here, I am going to discuss Single Sign On (SSO) feature as every other developer implements SSO on some or the other day.

So actually, I was having two applications. The requirement was like, user logins from one application and on clicking a link, it is navigated to another application. So when user clicks on the link, it is redirected to application2, it checks whether the user is authenticated or not. If authenticated, it can access application2 else gets redirected to the first application for Authentication. And once authenticated again, directly reaches the second application.

Here, both my applications were Web applications and form Authentication is used to authenticate the user. I had to devise some solution to implement SSO. I didn’t want to use the authentication code written on both applications so I used the first application only for Authentication. I thought of using the same authentication cookie that was created by the first application after authentication. And implemented this.

It worked very well. I was able to read the authentication cookie in another application and wrote the logic accordingly. I deployed both applications on my local machine and Test QA Server and it worked like a charm.

But… as soon as my application went into the actual test environment, it started barfing. Nothing was working. No SSO.. Nothing..

Actually, what happened was that both the applications were deployed on different web servers in different domains. Like my first application has URL like app1.mydomain.com and another one app2.mydomain.com.

As I was not aware earlier, I didn’t keep it in mind. As we know by default, cookie is limited to domain. I was not able to access auth cookie in application2 as it was in a separate domain. After some research on the Internet, I happened to make the changes in auth cookie and updated the domain property as I found solutions on Google. The code was like:

System.Web.HttpCookie MyCookie =
       System.Web.Security.FormsAuthentication.GetAuthCookie(User.Identity.Name.ToString(),
                                                             false);
MyCookie.Domain = ".mydomain.com";//the second level domain name
Response.AppendCookie(MyCookie); 

You can find it easily on the internet. But the actual nightmare started after this only. Users were not able to logout. It kept looping as I checked in Fiddler and finally redirection error. I started searching on the internet and found lots of people have problems but no thread ended with the proper solution. I found at some places the auth cookie doesn’t get deleted if domain is set. Some workarounds were there, like deleting the auth cookie manually when user logs out. But this also didn’t work. And ultimately, I did not find any solution on internet.

So I did some brainstorming. Actually, there is a method provided as...

FormsAuthentication.SignOut()

...which is supposed to logout the user once called but it was not doing it. Actually, as suggested over the internet, I set the domain for Auth cookie. Which was creating some problem? FormAutetication itself provides a way to set the domain for cookie. This is a static property of the FormAuthentication Class. But this is read only. One needs to set it in web.config file and it will also be easy. You can change the domain whenever you want. So one can set it as:

<forms name=".ASPXAUTH" 
loginUrl="Login/" protection="Validation" 
timeout="120" path="/" domain=".mydomain.com"/>

After setting my application again, it started working perfectly fine. So I wanted to share this with all of you. One does not need to update the cookie manually as I did in the first code sample above and later delete it while logging out. It may not work. Just one needs to set the domain at config file, one will be away from this endless problem and surfing the Internet.

Hope this helps!

Thanks for reading!

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