reprint to: http://www.onmpw.com/tm/xwzj/network_145.html
Detailed explanation of the implementation methods of SSO single sign-on in three situations
Single sign-on (SSO—Single Sign On) is no stranger to us. For large systems, using single sign-on can save users a lot of trouble. Take Baidu as an example. There are many subsystems under Baidu—Baidu Experience, Baidu Know, Baidu Wenku, etc. If we use these systems, each system requires us to enter a user name and password to log in once. I believe that the user experience will definitely plummet. Of course, single sign-on is simply not necessary for systems such as personal blogs .
Suppose our system is very large, but it is this system, and there are no subsystems. We also don't need single sign-on at this point. What we need is to build a cluster environment. Although there is only one system here, the problem of session sharing is involved in the load balancing of multiple hosts . Compared with SSO, the Session sharing problem will be easier to solve.
Well, let's forget about systems that don't require single sign-on. Three cases of SSO single sign-on have been indicated in the title. Let's introduce these three cases separately.
How to verify different sites under the same domain name
We know that PHP form validation is completely dependent on cookies. So, if two sites could share the same authentication cookie, it would be easy to log into multiple sites with the same user.
According to the HTTP protocol, two sites can share cookies. The premise is that the two sites are under the same domain name (or a second-level domain name). In this case, the cookies belong to the same domain. The browser stores the cookie and the domain to which the cookie belongs locally. When you visit any subsite under this domain, the browser will send these cookies to the site system.
Suppose we have two sites
www.onmpw.com/site1
www.onmpw.com/site2
Both sites share the same host address, and both are under the same domain name. Add that you have just logged into www.onmpw.com/site1 and your browser will have an authentication cookie from www.onmpw.com/site1. These cookies are sent to site1 when you click on any of the subpages under site1. This is easy to understand. Similarly, when you request www.onmpw.com/site2, these cookies will also be sent with the request for any page below site2. Why is this because the domain of the cookie stored on the browser side is www.onmpw.com. Both sites, site1 and site2, belong to the same domain. So for cookies under this domain, both sites can get it.
In this case, if the system is PHP, we don't need to do any special processing at all. Just follow the normal verification method to verify. Because the sessionId of the two is the same, as long as their session information is stored in the same place.
How to perform single sign-on on the same domain but different subdomains
If our site is deployed according to the following domain name
sub1.onmpw.com
sub2.onmpw.com
Both sites share the same domain, onmpw.com.
By default, the browser sends the host corresponding to the domain to which the cookie belongs. That is, the default domain for cookies from sub1.onmpw.com is .sub1.onmpw.com. Therefore, sub2.onmpw.com will not get any cookie information belonging to sub1.onmpw.com. Because they are on different hosts, and the subdomains of the two are also different.
In this case, if we use PHP to achieve, we can set the cookie information of both under the same domain.
First login to sub1.onmpw.com system
After the second login is successful, set the cookie information. It should be noted here that we can store the username and password in the cookie, but when setting it, the domain to which the cookie belongs must be set to the top-level domain .onmpw.com. Here you can use the setcookie function, the fourth parameter of this function is used to set the cookie for the domain.
setcookie(‘username’,’onmpw’,null,’.onmpw.com’);
setcookie(‘password’,’pwd’,null,’.onmpw.com’);
The third visit to the sub2.onmpw.com system, the browser will send the information username and password in the cookie to the sub2.onmpw.com system together with the request. At this time, the system will first check whether the session is logged in, if not, it will verify the username and password in the cookie to achieve automatic login.
The fourth sub2.onmpw.com log in successfully and then write the session information. After verification, you can use your own session information to verify.
Of course, the way to log in to sub2.onmpw.com first is the same. After the above steps, the single sign-on of different second-level domain names can be realized.
However, there is a problem here that after the sub1 system exits, in addition to clearing its own session information and cookie information whose domain is .onmpw.com. It does not clear the session information of the sub2 system. That sub2 is still logged in. That is to say, although this method can realize single sign-on, it cannot realize simultaneous logout. The reason is that although sub1 and sub2 can share cookies through the setting of the setcookie function, the sessionId of the two is different, and this sessionId is also stored in the form of a cookie in the browser, but the domain it belongs to is not .onmpw. com. That is to say, the sessionId of the two is different.
So how to solve this problem? We know that in this case, as long as the sessionId of the two systems is the same, this problem can be solved. That is to say, the domain to which the cookie that stores the sessionId belongs is also .onmpw.com. In PHP, sessionId is generated after session_start() is called. In order for sub1 and sub2 to have a common sessionId, the domain to which the sessionId belongs must be set before session_start(). There are two ways:
First use the php function ini_set function to set as follows
ini_set('session.cookie_path', '/');
ini_set('session.cookie_domain', '.onmpw.com');
ini_set('session.cookie_lifetime', '0');
The second directly modify the php.ini file
session.cookie_path = /
session.cookie_domain = '.onmpw.com'
session.cookie_lifetime = 0
After the above settings, the sub1 and sub2 systems will use the same session information. This enables both single sign-on and simultaneous logout.
How to implement single sign-on between different domains
Suppose we need to implement single sign-on between the following stations
www.onmpw1.com
www.onmpw2.com
www.onmpw3.com
For this situation, we have two implementations, of which we will first introduce the simpler implementation.
method one
In order to achieve single sign-on, when a user logs in to any one of these sites, we need to set cookie information on the browser side for each other site.
If the user logs in on the onmpw1 site, after the login is successfully authorized, the browser will store a copy of the cookie information of the onmpw1 site. At the same time, in order to log in to onmpw2 and onmpw3, we need to set cookies for onmpw2 and onmpw3 when the colleagues who set the cookie of onmpw1. Therefore, before responding to onmpw1, we need to jump to the onmpw2 and onmpw3 sites to set the cookie information.
The following figure is a single sign-on model for two sites (three drawings are more troublesome, in order to save time, two are used to represent, but the principle is the same)
The verification steps in this case are as follows:
1. The user requests a page that requires verification from www.onmpw1.com (hereinafter referred to as onmpw1).
[Status: The browser has not verified the cookie information]
2. The browser sends a request to onmpw1 (this request has no cookie information, because it has not yet stored the cookie information whose domain is onmpw1.com).
[Status: The browser has not verified the cookie information]
3. Onmpw1 finds that there is no cookie information in the request, so it redirects the request to the login page
[Status: The browser has not verified the cookie information]
4. The user submits the authentication information required for login and clicks the login button, the browser sends a post request to onmpw1.
[Status: The browser has not verified the cookie information]
5. Onmpw1 receives the submitted verification information and starts to verify the information. If authentication is successful, mark the user as logged in. A cookie with the logged in user information is then created and added to the response.
[Status: The browser has not verified the cookie information]
Sixth, onmpw1 does not respond to the browser's request for the time being. At this time, it will send the command to redirect to www.onmpw2.com (hereinafter referred to as onmpw2) to the browser, and it will also have the url address that needs to be returned on the onmpw2 site, which is originally in onmpw1. Because the cookie information is already in the response message, this cookie is also sent to the browser.
[Status: The browser has not verified the cookie information]
7. After the browser receives the verified cookie information and the response information of the command redirected to onmpw2, it sets the domain of the cookie information to onmpw2 and stores it locally, and wants to send the request to onmpw2. This request will carry the cookie information just now.
[Status: The browser already has cookie information whose domain is onmpw2]
8. onmpw2 will immediately redirect to the url address that needs to be returned, and obtain the cookie of onmpw1 by reading the cookie information sent by the browser. And this cookie is also sent to the browser.
[Status: The browser already has cookie information whose domain is onmpw2]
9. After receiving the information, the browser will store the cookie whose domain is onmpw1 locally. And send a request with cookie information to onmpw1 again.
[Status: The browser already has cookie information whose domains are onmpw2 and onmpw1]
10. After onmpw1 receives the verification information, it knows that the verification cookie has been set successfully. At this point, onmpw1 will return the corresponding request interface instead of the login interface.
[Status: The browser already has cookie information whose domains are onmpw2 and onmpw1]
So, when the user visits onmpw2 again, the cookie information has been stored in the browser. At this time, onmpw2 will read the information of the logged-in user in the cookie, and then provide the corresponding interface to the browser.
In this way, single sign-on has been set up successfully. In this example, following the above steps, after logging in onmpw1, onmpw2 and onmpw3 can log in at the same time.
How to log out
Now that we have implemented single sign-on, we still have to consider logout. Since you are logged in at the same time, you can't log out one by one when you log out! So we have to set up a single exit.
To achieve a single sign-out, in this example, what we need to do is that when one site is logged out, the cookies of the other two sites also need to be cleared in the browser. Only in this way can a single point of exit be achieved.
This is actually very simple. After understanding the above single sign-on process, single sign-out can be achieved by simply changing the setting verification cookie to removing the cookie from the response information according to the above steps.
In this case, whether it is single sign-on or single sign-out. There is a problem with both, in this case we just have three sites. If we say we have 10 sites of 20 or more in the whole system, redirecting back and forth like ours will be very inefficient.
Method 2
Next we will introduce another way. This method requires us to use a separate SSO service for verification purposes. And we also need to have a unified user data for users of different sites. Compared with the former method - the browser needs to store the cookie of each site - this method only needs to store the cookie information of the SSO service site. Use this cookie information with other sites for single sign-on. We temporarily call this SSO service site www.SSOsite.com (hereinafter referred to as SSOsite).
Under this model, requests to any site will first be redirected to SSOsite to verify the existence of an authentication cookie. If present, the authenticated page will be sent to the browser. Otherwise the user will be redirected to the login page.
To understand this approach, suppose now that we use this model to implement 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 special service site www.SSOsite.com (hereinafter referred to as SSOsite) for verification.
first part
Implementation process
· The user requests a page of onmpw1 that needs to be authenticated
· onmpw1 sends a command to the browser to redirect to SSOsite. And add a return address (ReturnUrl) parameter query string to the address, the value of this parameter is the address originally requested to onmpw1.
· SSOsite checks the request for an authentication cookie, or any user token. Without this information, it will be redirected to onmpw1 again. In the request redirected to onmpw1, there will be parameters to let the user log in the url parameter and the address of the original browser request to onmpw1 - ReturnUrl.
· onmpw1 checks the parameters of requests redirected from SSOsite. At this time, onmpw1 knows that the user needs to log in, so onmpw1 will redirect to the login interface and inform the browser that the request does not need to be redirected to SSOsite.
the second part
· The user provides authentication information and clicks the login button. No more redirects to SSOsite now. At this point, onmpw1 calls the web/WCF service in SSOsite to check the authentication information provided by the user. After successful authentication, the user object with the token attribute will be returned to onmpw1. And this token is generated every time the user logs in.
· onmpw1 marks that the user has successfully logged in, and then generates a URL address with the user token that redirects to SSOsite.
· SSOsite checks the received URL and finds the user token in it. Through this token, you can know that the user has successfully logged in to onmpw1, so SSOsite needs to prepare the cookie information for verification. Therefore, it will use the token to fetch user information in the cache to generate cookie information, and also set some other information (such as expiration time, etc.) in the cookie. Then add the cookie to the response message. Finally redirect to the original ReturnUrl address. At the same time, the token still has to be added to the query string and carried over.
· The browser gets redirected to onmpw1 and gets the cookie information from SSOsite. Therefore, the browser saves the cookie whose domain is SSOsite locally. Then take the token to request onmpw1.
· Now onmpw1 sees the user token in the query string parameter and will go through the web/WCF service again to validate the token on the SSOsite. After the verification is successful, the page that was originally requested will be sent to the browser for output to the user.
the third part
· The user now goes to request onmpw2.
· onmpw2 redirects to SSOsite, and also sets ReturnUrl to the page address of onmpw2 that was just requested.
· After the browser receives the redirection command, because the cookie of SSOsite exists locally, it will add the cookie to the request and send it to SSOsite.
· SSOsite checks the received request and finds cookie information. First, it will check whether the cookie information has expired. If it has not expired, it will extract the user token from the cookie. Then redirect to the address in the original onmpw2 with the token.
· onmpw2 finds that there is a user token in the request, and then he will verify the legitimacy of the token through the web/WCF service of SSOsite. After the verification is successful, the page originally requested by the browser for onmpw2 is sent to the browser for output to the user.
Summarize
Wow, looks like there's a lot to do. It's actually not that complicated.
At first, the browser had no cookie information belonging to the domain SSOsite. Therefore, whether you click on any site that requires authentication, you will jump to the login page (this process is internally redirected to SSOsite by the program to check for the existence of cookies). Once the user logs in successfully, the domain belongs to SSOsite, and the cookie with the logged in user information will be stored locally by the browser.
Then, when the user visits the page that needs to be authenticated again, the same request will be redirected to SSOsite, and the browser will bring the previously saved cookie information. SSOsite retrieves the cookie, extracts the user token from it, and redirects to the originally requested site page with this token. Then the site will verify the legitimacy of the token through the web/WCF service. The corresponding page is then sent to the client.
Once the user is logged into the site via this single sign-on model, requesting any page that requires authentication will internally redirect to SSOsite to authenticate the cookie and extract the user token, and then send the requested page to the browser for output.
This article is long and seems a bit verbose. But I always hope that the process can be explained clearly to everyone. Hope this article is helpful to you all.