Nice, good thinking.
Few suggestions for security:
1) Let login information directly collected by SSO site over SSL.
2) Use 128 bit certificate to encrypt the cookie. Let SSO write the cookie and pass it to requesting site and the requesting site will use private key to encrypt the cookie and SSO will use the public key to decrypt the cookie for validation. This way you may extend your solution for other partners where your SSO will depend on there certificate to decrypt it and the participating site will use there certificate for encyption.
3) cut down on redirections.
4) Write cookies in the domain of requesting site only, and disable use of cookie from scripts.
I would have to agree with Tim about his vote of 1.
Yes you [author] did a great demo project explaining a concept in simple terms however I would never state in such an article that it should be acceptable to be put in production in any website.
It's "simple" but that does not warrant the dangers of using this implementation.
There are so many things wrong from a security perspective:
1. There are basically no security features in your implementation.
2. There is no protection from a reply attack for example
3. You generate your own cookies. The ASP WebForms Auth cookies are there for a reason. They have protection mechanism in place for cookies to be altered and so on.
Implementing "your own" is not only a a risk to your app but to the other people who think your implementation is good.
4. You have no risk of someone trying to use your "SSO" service to connect an external site to your SSO.
5. There is no protection from a Login attack or a Token verify attack.
6. There is no protection from even a simple Phishing attack by messing up with the return URL
7. If your SSO server is down, all your sites are down as they rely on it way to much
8. 3 sites * 100 requests generate 300 web requests to your SSO.
9. ASP.Net webservices? c'mon
So, I love what you did from the perspective of "how SSO works" but PLEASE PLEASE PLEASE remove the "use in production" statement and put a bit red statement "this should never be used in a production system" before some guy with no experience uses this to protect his next big set of websites and then they sue you for professional liability. PLEASE.
OpenId, Passport, Facebook Login, Google Login, Microsoft Federated are all SSO designed, reviewed and tested by million of people and they all include some super-doper protections for all types of attacks. There is a reason people use OpenId and don't come up with their own "I can do it better".
Thanks for your insightful feedback. Yes, there are lots of scopes to improve the implementation, I don't disagree. I hope you have noticed the following piece of line:
"However, I’ll try to update the SSO model to enrich it with more features and make it robust so that, this could be used in commercial systems without requiring any customization."
Basically, I tried to develop the basic model which works. Handling the security issues is obviously important, before considering to use this in production, but, these are not something which is impossible to do. My concern was to develop the basic implementation first and share with the community. Later one, these cross-cutting issues surely can be addressed. I'll surely work on those, but hey, the source code is open, and, any one can customize it according to his/her need.
Please take my feedback and remove the comments that it can be used in a production system when you clearly know it has major security flaws and add a comment that it should NOT be used in any production system.
You really don't want to go and buy a car from a salesman who tells you the car is all good and safe but he knows the brakes don't work when you go downhill. It only needs some small tweaks but hey, you can use it on a flat surface with no issues it's not the type of comment you want from your car salesman.