ASP.NET - Single Sign On in asp.net

Asked By Naveen Thangathirupathy on 12-Jul-10 06:40 AM

Hi folks,


I am in need to implement Single Sign on for a group of asp.net web applications. So I went through few articles and   have done the following..

 I use forms authentication for my applications. I created an authentication ticket and attached it to a cookie which will be shared across applications. Now I am able to share the cookie between applications as i have same validation key and decryption key in all applications.  Do the single sign on ends up here??


Now i am bit confused with few questions in my mind..

1.Do the single sign on just require only browser cookies and nothing else??

2. If Cookies are the only thing needed, then will it be secure secure?

3. Will it be scalable for 5000 users at an instance??

3. DO we need SSL certificate? Is it mandatory?

4. Dont we need any database to save sessions and track them between applications?


Could anyone help me by shedding some light on these areas??

Christiano Coutinho replied to Naveen Thangathirupathy on 12-Jul-10 12:36 PM
Hi There!

1.Do the single sign on just require only browser cookies and nothing else??
Yes, but I think your application also uses Validators and other .Net components that embed javascript code.

2. If Cookies are the only thing needed, then will it be secure secure?
Encrypted cookies are safe, and even asp.net authentication uses it.

3. Will it be scalable for 5000 users at an instance??
It's hard to say. It depends a lot on wich encryption algorithm you have used, and the resources needed by it. I suggest you to use a hash in this cookie when you don't have to read all the content again. So, you have only to see if there is a match on the hashes, instead of decrypting all it content every postback. I also suggest you to use an .net profiler to calculate the optimal hardware to support the users you have to.


3. DO we need SSL certificate? Is it mandatory?
This is not mandatory, but it's a good idea to force it on the login process (only there) to ensure secutiry on credentials transmission from the browser. For example: Gmail uses https only at login. The other pages are accessed by HTTP. Force HTTPS on every page is a bad move.

4. Dont we need any database to save sessions and track them between applications?
this is a good aproach, and the asp.net applications can be configured to use session persistence in SQL Server. But this is not mandatory on single sign on. If your encripted cookie has everything the applications need to know, I think the session persistence on database will not affect your strategy. This strategy is useful specially in a web farm, when the original server where you opened the session is down and another one will resume this session.

Good luck!

Michael replied to Christiano Coutinho on 12-Jul-10 03:12 PM
I'm not sure if GMail has changed but I'm on an encrypted connection with them from the time I type www.gmail.com in my browser until I log out or close my tab.

Also, don't rely on just cookies to authenticate your users.  If a hacker sniffs the authenticated cookie and steals it then they can still access the user's account.  So, you should implement some sort of matching of authenticated cookies to a terminal name and IP address.  This can be stored in the database.  This way, even if someone intercepts the authentication cookie the database will tell the application the identity of the computer the user is on and your application can then see the authenticated user's machine and the hacker's machine are different and then redirect the hacker's machine to the login page.
Christiano Coutinho replied to Michael on 12-Jul-10 04:08 PM
In Gmail, you can enable/Disable the https. But anyway, you have to consider this because when you keep all yous pages in HTTPS/SSL, the overhead from server is increased significantly. 

About the IP restriction on the cookie, I agree with you. But I assumed you have also inserted such information inside it. So, you have to check if it's correct only in some points (instead doing it every time you load your page). After checked, you can consider check the Hash and IP only.

Good luck!
Michael replied to Christiano Coutinho on 12-Jul-10 04:13 PM
Storing the IP within the cookie isn't doing anything if it's intercepted as it can be changed.  If they are dedicated then they could spoof packet headers but that's beyond this discussion.  The IP should be requested from the current user's context and compared with the IP that is logged for that user in the database.  Same? Fine.  Different? Direct them to the login page.
Michael replied to Christiano Coutinho on 12-Jul-10 04:14 PM
The reason I also added that their machine name should be captured is due to private networks.  That way you can not only verify the originating IP, or network for an office or home environment, but also the terminal itself.
Christiano Coutinho replied to Michael on 12-Jul-10 04:18 PM
That's great. Your solution seems to be awesome. 
I hope that my posts can help you somehow.

Good luck!