Geek Answers Handbook

How to implement single sign-on in .Net?

What is the best solution for implementing single sign-on in a .net application? I googled and found some solutions, but I am not very convinced of these solutions.

The user logs on to website1, and then goes to website2. How will site2 know that the user is logged in? I assume by passing some token in the url that will be checked by site2 in the database for credibility. Does this mean that I need to arrange all the URLs on website1, which is occupied by website2?

Secondly, if the user continues browsing website2, say 1 hour, then go to website1. By that time, the session with the website1 has expired, so the user will see the login page, right? But this behavior is incorrect due to a single feature of functionality.

+6
single-sign-on
source share
6 answers

I think you don’t understand how single sign-on works.

Let's look at website1 and site2 that want to use one single.

A website with an identifier is created. This is the only place the login screen appears.

When a user visits website1 and selects a login, site1 sends the user to the identityProvider login screen. The user logs on to identityProvider, which drops its own cookie for its domain (and possibly allows the user to save their authentication information so that they are no longer requested). Then it redirects the browser back to website1, including the token in the request that opens on website1, receives the identification information and executes its own login bits (discarding its own cookie authenticator, which continues, although it wants to).

Then the user visits site2 and selects the login. Website2 bounces from the user to the Provider identifier, which already knows who the user is, and if the user decides to save his registration information, silently authenticates and then redirects back to website2 with another token that opens on site2, and then executes its own bits entrance.

There is a bunch of security there, restricting tokens to specific websites, only allowing tokens to be sent to white sites, etc. etc.

So, to solve your problems

  • The user logs on to website1, and then goes to website2. How will site2 know that the user is logged in? This is not true. website2 must first request authentication information from the single site.
  • Does this mean that I need to sort all the URLs on website1 which is occupied by website2? Not unless you make website1 an identity provider too. Even then it would hurt, it is better to have the website 2 redirected back to the identifier if a token is required.
  • Secondly, if the user continues to browse website2, say 1 hour, then go to website1. By that time, the session with the website1 has expired, so the user will see the login page, right? - It depends on how you set up the website1 and how long it has been supporting the authentication cookie.
  • But this behavior is incorrect due to a single feature of functionality. No no. Single signon does not mean that you get a floating token that is shared between sites. Each website that uses single sign-on still creates its own authentication cookie. What can happen if a user returns to site1, he finds an expired cookie for authentication, and then sends the user back to the single sign-on page, where they authenticate (silently), and a new token returns to site1, which creates a new authentication cookie for himself .
+14
source share

Microsoft's formal approach is through Active Directory Federation Services (which wraps SAML with AD authentication). This has the characteristics you are looking for - but perhaps too heavy for a public web application.

+3
source share

I assume that you do not want to use Windows authentication with Active Directory, etc. One way is to transfer one authenticated session to another using the security token in the query string, as you described.

Both applications use the same public encryption key to encode / decode a security token. As you say, this works great if you have limited predefined cross-site navigation, but if you want to use any links to pages between applications, you will need to generate these URLs on the fly to contain the token.

How do you feel about timeouts is that the security token also contains the expiration time. You generate a new security token for each page request or when you create a new link between applications.

Typically, a security token contains a user ID and a timeout, and a login check either returns a user ID or null if the timeout expires.

This is not a quick solution for correct and secure coding. Maybe you can find the built in Code Project?

+3
source share

You can use different single sign-on mechanisms for different applications based on your application.

However, to provide authentication, supporting SAML, I could see the service outgoing SSO service from Live, Google, Yahoo, Facebook, etc. This will help us get rid of the problems that support our own implementation of single sign-on services.

If you need to understand how SSO works, you can link here

+1
source share

MS made a document on it as part of Enterprise a few years ago - we set up the samples, but never really implemented it - Single Sign-on

0
source share

Check out this link with OAuth and Social providers, it offers many authentication options already provided with .Net Microsoft OAuth instructional video and SSO with social providers

0
source share

More articles:


All Articles