SSO Single Sign-on three ways to implement the details

Single Sign-On is no stranger to us sso--single. Using Single sign-on for large systems can reduce a lot of hassle for users. Take Baidu, Baidu, there are a lot of subsystems-Baidu experience, Baidu know, Baidu Library and so on, if we use these systems, every system needs us to enter the user name and password login once, I believe that the user experience will definitely fall straight. Of course, there is no single sign-on for a system such as a personal blog.

If our system is very large, but this one system, and there is no subsystem. At this point we do not need a single sign-on. What we need is to build a cluster environment, although there is only one system, but the load balance of multiple hosts is related to the issue of session sharing. Session sharing issues are easier to solve than SSO.

Well, we don't need a single sign-on system. There are three cases of SSO single sign-on that have been identified in the topic, and we will describe each of the three cases below.

how the different sites under the same domain are validated

We know that PHP forms validation is entirely dependent on cookies. So, if two sites can share the same authentication cookie, it would be easy to use the same user to log on to multiple sites.

According to the HTTP protocol, two sites are allowed to share cookies. The premise is that these two sites are under the same domain name (or two level domain name can also). This situation is a cookie that belongs to the same domain. The browser will place the cookie and the domain the cookie belongs to locally. The browser sends these cookies to the site system when you access any sub-sites under that domain.

Let's say we have two of sites

Www.onmpw.com/site1 Www.onmpw.com/site2

The two sites share the same host address and both are under the same domain name. Join you just logged in to Www.onmpw.com/site1, your browser will have a cookie from Www.onmpw.com/site1 's identity verification. These cookies will be sent to Site1 when you click on any of the sub-pages under Site1. This is very easy to understand. Similarly, when you request Www.onmpw.com/site2, these cookies will also be sent in the past with the request for any page under Site2. Why is this, because the domain of cookies stored on the browser side is www.onmpw.com. Site1 and site2 two sites belong to the same domain. So for cookies under this domain, two sites are available.

In this case, if the system is PHP, we do not need to do any special processing. Just follow the normal verification method. Because the SessionID of the two are the same, as long as their session information is stored in the same place.

Single Sign-on for the same domain but different subdomains

If our site is deployed according to the following domain name

Sub1.onmpw.com sub2.onmpw.com

These two sites share the same domain onmpw.com.

By default, the browser sends the host for the domain to which the cookie belongs. In other words, the default domain that the cookie from sub1.onmpw.com belongs to IS. sub1.onmpw.com. Therefore, sub2.onmpw.com does not receive any cookie information that belongs to sub1.onmpw.com. Because they are on different hosts, and the subdomains of both are different.

In this case, if we use PHP to implement, we can set the cookie information of both in the same domain.

First Login sub1.onmpw.com System

After the second login is successful, set the cookie information. It is important to note that we can store the username and password in a cookie, but the domain of the cookie must be set to the top-level domain when set. onmpw.com. Here you can use the Setcookie function, the fourth parameter of the function is used to set the domain of the cookie.

Setcookie (' username ', ' ONMPW ', null, '. onmpw.com '); Setcookie (' Password ', ' pwd ', null, '. onmpw.com ');

Third access to the sub2.onmpw.com system, the browser sends the information in the cookie username and password to the sub2.onmpw.com system together with the request. At this point the system will first check whether the session is logged in, if not logged in to verify the cookie username and password in order to achieve automatic login.

IV sub2.onmpw.com Log in successfully after the session information. Later verification will be verified with your session information.

Of course, the same way of logging in to sub2.onmpw.com first. With the above steps, you can achieve a single sign-on with different level two domain names.

However, one problem here is that the SUB1 system exits, except that it can clear its own session information and the cookie that belongs to the domain. onmpw.com. It does not clear the session information of the SUB2 system. That SUB2 is still logged in. This means that although single sign-on can be implemented, it is not possible to exit at the same time. The reason is that sub1 and sub2 can share cookies through the settings of the Setcookie function, but the sessionid of the two are different, and this sessionid is stored as a cookie in the browser, But the domain it belongs to is not. onmpw.com. In other words, the sessionid of the two are different.

So how do we solve this problem? We know that this problem can be solved as long as the sessionid of the two systems is the same for this situation. This means that the SessionID cookie belongs to the same domain as the. onmpw.com. In PHP, SessionID is generated after the session_start () call. In order for Sub1 and sub2 to have common SessionID, it is necessary to set SessionID's owning domain before Session_Start (). There are two ways of doing this:

First Use the PHP function Ini_set function to set the following

Ini_set (' Session.cookie_path ', '/'); Ini_set (' Session.cookie_domain ', '. onmpw.com '); Ini_set (' session.cookie_lifetime ', ' 0 ');

Second direct modification of the php.ini file

Session.cookie_path =/Session.cookie_domain = '. onmpw.com ' session.cookie_lifetime = 0

After the above setup, the Sub1 and SUB2 systems will use the same session information. This enables both single sign-on and simultaneous exit.

How to implement single sign-on between different domains

Let's say we need to implement single sign-on between the following stations.

Www.onmpw1.com www.onmpw2.com www.onmpw3.com

In this case, we have two implementations, in which we first introduce the simple way to implement.

Way One

To achieve single sign-on, when a user logs in to any of these sites, we need to set cookie information on the browser side for each other site.

If a user logs on at the ONMPW1 site and the login is successfully authorized, the browser will store a portion of the cookie information for the ONMPW1 site. Also, in order to be able to log in to Onmpw2 and ONMPW3, we need to set cookies on Onmpw2 and ONMPW3 for colleagues who set up onmpw1 cookies. So before we respond to ONMPW1, we need to jump to the ONMPW2 and ONMPW3 sites to set up cookie information.

is the single sign-on model for two sites (three of the pictures are more troublesome, in order to save time, use two to represent, but the principle is the same)

The verification steps for this scenario are as follows:

One, the user to www.onmpw1.com (hereinafter referred to as ONMPW1) request a page to be verified.

[Status: Cookie information not verified by browser]

Second, the browser sends a request to ONMPW1 (the request does not have cookie information because it has not stored the cookie information that belongs to the domain onmpw1.com).

[Status: Cookie information not verified by browser]

Third, ONMPW1 found that there is no cookie information in the request, so it redirects the request to the login page

[Status: Cookie information not verified by browser]

Four, the user submitted the login required to verify the information and click the login button, the browser sends a POST request to ONMPW1.

[Status: Cookie information not verified by browser]

V. ONMPW1 receive the submitted validation information and begin to verify the information. If the validation succeeds, the user is marked as logged in. A cookie with logged-in user information is then created and added to the response information.

[Status: Cookie information not verified by browser]

Vi. ONMPW1 temporarily not responding to browser requests. It will then send a command to the browser that redirects to www.onmpw2.com (hereinafter referred to as ONMPW2), and also has a URL address that needs to be returned at the ONMPW2 site, which is in the original ONMPW1. Because the cookie information is already in the response message, the cookie is also sent to the browser.

[Status: Cookie information not verified by browser]

After the browser receives the message with the authenticated cookie and the response to the command redirected to ONMPW2, the domain of the cookie information is set to ONMPW2 to be stored locally, and the request is onmpw2 to be sent. This request will contain the cookie information that you just made.

[Status: There are already cookie information in the browser that belongs to the domain ONMPW2]

Viii. Onmpw2 immediately redirects to the URL address that needs to be returned and obtains a cookie to ONMPW1 by reading the cookie information sent by the browser. and send this cookie together with the browser.

[Status: There are already cookie information in the browser that belongs to the domain ONMPW2]

Nine, after receiving this information, the browser will store the cookie that owns the domain ONMPW1 locally. and send a request with cookie information to ONMPW1 again.

[Status: Cookie information in the browser that has a domain of ONMPW2 and ONMPW1]

Ten, ONMPW1 received the verification information, know that the authentication cookie has been set successfully. At this point ONMPW1 will return to the corresponding request interface instead of the login interface.

[Status: Cookie information in the browser that has a domain of ONMPW2 and ONMPW1]

So, when the user accesses onmpw2 again, the cookie information is stored in the browser. At this point Onmpw2 will read the user's information in the cookie, and then provide the appropriate interface to the browser.

This way, single sign-on is already set up successfully. In this example, following the steps above, ONMPW2 and ONMPW3 can log in at the same time after logging in to ONMPW1.

How to log Out

Now that we have implemented single sign-on, we have to consider the issue of exit. Since it is logged in at the same time, it can not be quit at the time of one of the exit bar! So we have to set up a single point of exit.

To achieve a single point of exit, in this case, we need to do is when a site exits, the other two sites of the cookie also need to be purged in the browser. This allows for a single point of exit.

This is actually very simple, after understanding the single sign-on process, the single point of exit simply follow the above steps to change the set of authentication cookie to remove the cookie from the response information can be achieved.

In this case, whether it is a single sign-on or single-point exit. There is a problem, in this case we just have three sites. If our entire system has 10 or 20 or more sites, the redirect back and forth like ours can affect efficiency.

Way Two

Let's introduce another way. This approach requires us to use a separate SSO service, specifically for validation purposes. And we also need to have a unified user data for users of different sites. In contrast to the previous approach--the browser needs to store the cookie--for each site, this way the browser only needs to store cookie information from the SSO Service site. Use this cookie information for a different site to enable single sign-on. For the moment, we will make this SSO Service site www.SSOsite.com (hereinafter referred to as Ssosite).

In this model, requests for any site will be redirected to Ssosite first to verify the existence of an authentication cookie. If present, the validated page is sent to the browser. Otherwise the user will be redirected to the login page.

To understand this, let's now assume that we are using this model to achieve single sign-on for the following two sites.

Www.onmpw1.com (hereinafter referred to as ONMPW1) www.onmpw2.com (hereinafter referred to as ONMPW2)

And we also have a dedicated service site www.SSOsite.com (hereinafter referred to as Ssosite) for verification.

The first part

Implementation process

• A user requests a page that needs to be validated by ONMPW1

ONMPW1 sends a command to the browser to redirect to Ssosite. and add a return address (RETURNURL) parameter to the address query string, which is the address that was originally requested by ONMPW1.

· Ssosite will check the request for an authentication cookie, or any user token. Without this information, it is redirected to Onmpw1 again, and in requests redirected to ONMPW1, a URL parameter that allows the user to log in and the address--returnurl of the original browser request ONMPW1.

ONMPW1 detects the parameters of the request from the Ssosite redirect. At this point Onmpw1 learned that the user needs to log on, so ONMPW1 redirects to the login interface and notifies the browser that the request is no longer redirected to Ssosite.

Part II

• The user has provided authentication information and clicked the Login button. Now it's not going to redirect to Ssosite. At this point, ONMPW1 calls the WEB/WCF service in Ssosite to check the authentication information provided by the user. Successful validation returns the user object with the token attribute to ONMPW1. And this token is generated every time a user logs in.

ONMPW1 The user has logged in successfully, then generates a URL address that will be redirected to ssosite with the user token.

· Ssosite checks the received URL address where the user token is found. The token lets you know that the user has successfully logged in to ONMPW1, so Ssosite needs to prepare the cookie information for verification. As a result, it uses tokens to extract user information from the cache to generate cookie information, and also to set some other information in the cookie (such as expiration time, etc.). The cookie is then added to the response message. Finally redirect to the original ReturnUrl address. The token is also added to the query string with the past.

• The browser gets redirected to the ONMPW1 command, and the cookie information is obtained from the ssosite. Therefore, the browser stores the cookie that belongs to the domain Ssosite locally. Then take token to request ONMPW1.

• Now ONMPW1 See the user token in the query string parameter, and then again through the WEB/WCF service to verify tokens on the ssosite. After validation succeeds, the page that was originally requested is sent to the browser for output to the user.

Part III

• Users now go to request onmpw2.

onmpw2 Redirect to Ssosite, also set ReturnUrl as the page address of the ONMPW2 that just started the request.

• After the browser receives the redirected command, the cookie is added to the request and sent to Ssosite because there is a local ssosite cookie.

· Ssosite checks that a cookie is found in the received request, first checks that the cookie information is expired and, if it does not expire, extracts the user token from the cookie. Then redirect to the address in the original ONMPW2 with token.

Onmpw2 found a user token in the request, and then he verifies the legitimacy of the token through the Ssosite WEB/WCF service. After validation succeeds, the page that originally requested ONMPW2 the browser is sent to the browser for output to the user.

Summary

Wow, there seems to be a lot of things to do. It's not that complicated, actually.

Initially, the browser does not have cookie information that belongs to the domain ssosite. So whether you click on any site to verify the interface will jump to the login page (this process is redirected from within the program to Ssosite to check for the existence of cookies). Once the user is logged on successfully, the owning domain is ssosite and the cookie with the logged-in user information is stored locally by the browser.

Then, when the user accesses the page that needs to be verified again, the same request is redirected to Ssosite, and the browser brings the cookie information that was previously saved. Ssosite retrieves the cookie, extracts the user token from it, and redirects the token to the originally requested site page. The site then verifies the legitimacy of tokens through the WEB/WCF service. The corresponding page is then sent to the client.

Once the user logs on to the site through the single sign-on model, requests that any page that needs to be validated is internally redirected to the Ssosite authentication cookie and the user token is extracted, and the requested page is sent to the browser output.

Read the original

SSO Single Sign-on three ways to implement the details