What is the best solution to implement single sign on in a .net application? I have googled and found few solutions but I am not very convinced with those solutions.
User logs on website1 and then moves to website2. How website2 will know user has logged in? I guess by passing some token in the url which will be checked by website2 in database for validity. That means I need to marshall all the urls in website1 which takes to website2?
Secondly if user continue to browse website2 for say 1 hour and then move to website1. By that time website1 session has timed out so user will see a login page, isn't it? But this behavior is wrong as per single sign on functionality.
I think you're misunderstanding how single sign-on works.
Lets consider website1 and website2 who want to use single signon.
A login website is created at identityProvider. This is the only place where a logon screen appears.
When the user visits website1 and choose to login website1 sends the user to the logon screen at identityProvider. The user logs onto identityProvider which drops its own login cookie for its domain (and perhaps allows the user to save their authentication information so they're never prompted again). It then redirects the browser back to website1 including a token in the request which website1 cracks open, gets identity information from and performs it's own login bits (dropping it's own authentication cookie which lasts for however it wants).
Then the user visits website2 and selects logon. Website2 bounces the user to identityProvider, who already knows who the user is and, if they user has chosen to save their login information, silently authenticates and then redirects back to website2 with another token which website2 cracks open and then performs its own login bits.
There's a bunch of security around it, limiting tokens to particular websites, only allowing tokens to be sent to whitelisted web sites etc. etc.
So to address your concerns
- User logs on website1 and then moves to website2. How website2 will know user has logged in? It doesn't. website2 must request authentication information from the single signon site first.
- That means I need to marshall all the urls in website1 which takes to website2? No, unless you make website1 the identity provider too. Even then that would be painful, better to have website2 redirect back to the identityprovider if a token is necessary.
- Secondly if user continue to browse website2 for say 1 hour and then move to website1. By that time website1 session has timed out so user will see a login page, isn't it? - It depends how you configure website1, and how long it's authentication cookie lasts for.
- But this behavior is wrong as per single sign on functionality. No it's not. Single signon does not mean you get a floating token that is shared between sites. Each website which uses the single sign-on still creates their own authentication cookie. What might happen is if the user goes back to website1 it detects an expired authentication cookie, then sends the user off to the single signon page again where they're authenticated (silently) and a new token is pushed back to website1 which creates a new authentication cookie for itself.
The official Microsoft approach is via Active Directory Federation Services (which wraps SAML with AD authentication). This has the characteristics which you're looking for -- but is possibly too heavyweight for a public web application.
I'm assuming that you don't want to use Windows Authentication with Active Directory, etc. One method is to hand over from one authenticated session to the other using a security token on the query string, as you describe.
Both applications use the same public encryption key to encode/decode the security token. As you say, this works fine if you have limited, predefined transition links between the sites but if you want to be able to use any page links between the apps you would need to generate those urls on the fly so that they contain the token.
The way you deal with timeouts is that the security token also contains an expiry time. You generate a new security token each page request, or when you create a new link between apps.
Typically the security token contains a userid and a timeout and the login checker either returns the userid or null if the timeout has expired.
It's not a quick solution to code up properly and securely. Maybe you can find a pre-built one on Code Project?
You can use different SSO mechanism for different application based on your application.
Using Machine Config
Single Sign-on Within a Second Level Domain
Cross Domains Using Common database(Implementation should be taken care by us)
However, I could see "Out-of-box SSO" service from Live, Google, Yahoo, Facebook etc. to provide authentication by supporting SAML. This will help us to get rid of the issues maintaining our own SSO service implementation.
If you need a basic understanding how the SSO Work, You can refer here
MS did a paper on it within the Enterprise a few years back - we set-up the samples but never implemented it for real - Single Sign-on
Check out this link with using OAuth and Social providers, it offers a multitude of authentication capabilities already cooked into .Net Microsoft training video on OAuth and single sign on with social providers
来源：https://stackoverflow.com/questions/1211431/how-to-implement-single-sign-on-in-net