Detailed cross-domain single sign-on (SSO) implementation scheme "with. NET code" _ Practical Tips

SSO Introduction

Defined:

The traditional single site login access authorization mechanism is: After the successful login to save the user information in the session, SessionID saved in the cookie, each access needs to access the resources (URL) to determine whether the current session is empty, for empty words jump to login interface login, Allow access if not empty.

Single sign-on is a multi-site shared login access authorization mechanism that allows access to resources (URLs) that other sites need to log on to if they are logged on at one site. If a user logs off at any one site, the logon status of the other site is also logged off. In short, a login, log in everywhere. A cancellation, cancellation everywhere.

Application Scenario:

When a Web site system slightly more complex, the need to split the business, such as an electrical business site, can be a product search, merchandise details, shopping carts, orders, such as split into subsystems. When a system is split into multiple subsystems, a single sign-on is required for authorization.

Business requirements:

Recently the company because of business needs to develop a number of subsystems need to be integrated with the main station, on the Internet to see a lot of single sign-on tutorial, a comprehensive variety of situations summed up the following single sign-on implementation ideas. It uses the idea of polling jump to solve the problem of writing cookies to multiple stations at the same time. If there are any irregularities, you are welcome to criticize.

Implementation features:

1. Can be completely cross-domain

2.url transparent (no URL transfer token or ticket is required for a stop jump)

3. Synchronous logoff

4. Write cookies to multiple stations at a time

Effect preview:

Realize the idea

Implementation difficulties:

The difficulty with this approach is how to write cookies to the B.Com at the same time as a.com log in. The way I use it is now to maintain a collection of sso.com in the log and write cookies to the various stations in the form of polling jumps after the login is successful.

Specific ideas:

1. First visit a.com-> Click on the a.com page of the login button-> jump to sso.com for login verification-> Login successfully after the data stored in the cache-> Then, in order to poll jumps, access each of the stations in turn and write cookies to the various stations-> finally jump to the login source page

2. After successful login-> access to the resource (URL) that needs to be logged in-> send a request to sso.com for cookie validation-> authentication by accessing the resource

Code Analysis

1. New Three sites: a.com,b.com,sso.com

2. Create a new Home/index page in A.com, as follows:

The first access cookie does not exist and returns an error when the Sso.com/login/validatelogin is validated in the form of a mock request, and the page displays the status of the login
The corresponding view page is as follows:

Sso.com/login/validatelogin the corresponding code:

3. Click the login button on A.com's homepage to jump to the sso.com login page (login/index)

The login code in 4.sso.com is as follows:

5. Click Login to enter the login authentication method

Generate token, save user information as key token in cache and set expiration time

To get a collection of stations, write a cookie to each of the stations in turn by redirecting the polling, and finally redirect to the login source page

Logon authentication methods are as follows:

The method code for the a.com and B.Com in the skip-transliteration cookie is as follows:

///<summary>///write cookies in the form of a jump///</summary>///<param Name= "token" > Authorized token </param>///<param name= "Others" > a series of substation </param>///<param name= "main" > Login successfully returned to the site </param>///<returns></returns> public actionresult Jump (string token, String othe
      RS, string main) {HttpCookie cookie = new HttpCookie ("CurrentUser"); Cookie.
      HttpOnly = true; Cookie. Expires = DateTime.Now.AddYears (100);//Never Expires cookies.
      Value = token;

      RESPONSE.COOKIES.ADD (cookie); In turn, subtract the!string that has already been written to the cookie. IsNullOrEmpty (Others)) {//Get collection of stations var substationlist = others. Split (new char[] {', '}, Stringsplitoptions.removeemptyentries).
        ToList ();
        if (Substationlist.count = = 1) {return Redirect (others + "&main=" + main);
      else {string currentredirect = substationlist[0];    Substationlist.removeat (0); String Otherss = String.
          Join (",", substationlist);
        Return Redirect (Currentredirect + "&others=" + Otherss + "&main=" + main); } else {return Redirect (main);//Jump to login source page}} 

6. Return to the Login source page a.com/home/index or B.com/home/index

At this point, a.com and B.Com already have cookies.

7. Log out (logout) processing

Log out directly call the Sso.com/login/loginout method, as follows:

Summarize

This way, the user login information is stored in the cache in the sso.com, and the cache key as a cookie to save the value of the various stations to achieve a Cross-domain single sign-on

The difficulty with this approach is how to write cookies to the B.Com at the same time as a.com log in. The way I use it is now to maintain a collection of sso.com in the log and write cookies to the various stations in the form of polling jumps after the login is successful.

This approach also has a number of problems when implementing Cross-domain single sign-on:

1. No consideration of AJAX login

2. No security verification (IP Trust, cookie hijacking, brute force login ...)

Consider the deficiencies, sincerely hope that you can put forward good ideas and additional views

Demo Download: Demo

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.