Shulou(Shulou.com)06/02 Report--

Xiaobian today takes you to understand what the three ways to implement Linux single sign-on are, and the knowledge points in the article are introduced in great detail. Friends who feel helpful can browse the content of the article together with Xiaobian, hoping to help more friends who want to solve this problem find the answer to the question. Below, follow Xiaobian to learn in depth the knowledge of "What are the three implementation methods of Linux single sign-on?"

In B/S systems, login functions are usually implemented based on cookies. When the user logs in successfully, the login status is generally recorded in the Session, or a Token is issued to the user. Either way, some information (Session ID or Token) needs to be saved in the client, and the client is required to carry them in each subsequent request.

Single Sign On (SSO) refers to multiple application systems under the same account platform, users only need to log in once to access all mutually trusted application systems.

In such a scenario, the use of cookies is undoubtedly the most convenient, so we generally save the Session ID or Token to the Cookie, when the server receives the request, by verifying the information in the Cookie to determine whether the user logs in.

For example, Baidu Post Bar and Baidu Map are two different application systems owned by Baidu Company. If the user does not need to log in again when he visits Baidu Map after logging in Baidu Post Bar, it means that Baidu Post Bar and Baidu Map have realized single point login.

The essence of single sign-on is to share login status among multiple applications. If the login status of the user is recorded in the Session, to share the login status, it is necessary to share the Session first. For example, you can serialize the Session into Redis, so that multiple application systems share the same Redis, and directly read Redis to obtain the Session.

Of course, this alone is not enough, because different application systems have different domain names. Although Session ID is shared, because Session ID is often stored in browser cookies, there are scope restrictions and cannot be transferred across domain names. That is to say, when a user logs in to app1.com, Session ID will only be automatically carried in the request header when the browser visits app1.com, and Session ID will not be carried when the browser visits app2.com The key to achieving single sign-on is how to share the Session ID (or Token) across multiple domains.

Implementation Method 1: Parent Domain Cookies

Before we get into specifics, let's talk about the scope of cookies.

The scope of a Cookie is determined by both the domain and path attributes. Valid values for the domain attribute are the domain name/IP address of the current domain or its parent domain. In Tomcat, the domain attribute defaults to the domain name/IP address of the current domain. Valid values for the path attribute are paths that start with "/," and in Tomcat the path attribute defaults to the context path of the current Web app.

A cookie is considered a parent domain Cookie if its domain property is set to the parent domain of the current domain. Cookies have the property that cookies in the parent domain are shared by child domains, in other words, child domains automatically inherit cookies from the parent domain.

Taking advantage of this feature of cookies, it is not difficult to think of saving the Session ID (or Token) to the parent domain. Yes, we just need to set the domain attribute of the Cookie to the domain name of the parent domain (primary domain name), and set the path attribute of the Cookie to the root path, so that all subdomain applications can access this Cookie.

However, this requires that the domain name of the application system be established under a common primary domain name, such as tieba.baidu.com and baidu.com, which are established under the primary domain name baidu.com, so they can achieve single sign-on in this way.

Summary: This implementation is relatively simple, but does not support cross-primary domain names.

Implementation 2: Certification Center

We can deploy an authentication center, which is a separate Web service dedicated to handling login requests.

Users log in uniformly at the authentication center. After successful login, the authentication center records the user's login status and writes Token into Cookie. (Note that this Cookie belongs to the authentication center, and the application system is inaccessible.)

The application system checks whether the current request has a Token. If not, it means that the user has not logged in in the current system, so the page will jump to the authentication center. Since this operation automatically brings the Cookie of the authentication center, the authentication center can know whether the user has logged in according to the Cookie.

If the authentication center finds that the user has not logged in, it will return to the login page and wait for the user to log in. If it finds that the user has logged in, it will not let the user log in again, but will jump back to the target URL and generate a Token before jumping. It will be spliced behind the target URL and sent back to the target application system.

After the application system gets the Token, it also needs to confirm the legitimacy of the Token to the authentication center to prevent the user from forging. After confirmation, the application system records the user's login status, writes the Token into the Cookie, and then releases the visit. (Note that this Cookie is for the current application system, and other applications are inaccessible.) When the user visits the current application system again, it will automatically bring this Token. The application system verifies that the Token has found that the user has logged in, so there will be no authentication center.

Here are two open source implementations of certification centers:

Apereo CAS is an enterprise-class single sign-on system, where CAS stands for "Central Authentication Service." Originally a Yale University laboratory project, it was transferred to JASIG, renamed JASIG CAS, and later merged into the Apereo Foundation, renamed Apereo CAS.

XXL-SSO is a simple single sign-on system, developed by Xu Xueli, a public comment engineer. The code is relatively simple and there is no security control. Therefore, it is not recommended to apply it directly to the project. It is listed here for reference only.

Summary: This implementation is relatively complex, supports cross-domain, good scalability, and is a standard practice for single sign-on.

Implementation Method 3: LocalStorage Cross-domain

Earlier, we said that the key to achieving single sign-on is how to make the Session ID (or Token) shared among multiple domains.

Parent-domain cookies are a good solution, but cross-domain cookies are not supported. So are there any tricks to make cookies cross domains?

Unfortunately, browsers are becoming more restrictive on cookies across domains. Chrome also adds a SameSite attribute to cookies, which prohibits almost all cross-domain cookie requests (except hyperlinks) and allows cookies from servers to be accepted in AJAX cross-domain requests only if the HTTPs protocol is used.

However, in the case of separation between the front and back ends, cookies can be completely omitted. We can choose to save the Session ID (or Token) to the LocalStorage of the browser, so that the front end actively passes the LocalStorage data to the server every time it sends a request to the back end. These are all controlled by the front end, and all the backend needs to do is to put the Session ID (or Token) in the response body and pass it to the front end after the user logs in successfully.

In such scenarios, single sign-on can be implemented entirely on the front end. After the front end gets the Session ID (or Token), in addition to writing it to its own LocalStorage, it can also write it to LocalStorage under multiple other domains by special means.

The key codes are as follows:

//Get token var token = result.data.token;//Dynamically create an invisible iframe, load a cross-domain HTMLvar iframe = document.createElement("iframe");iframe.src = "http://app1.com/localstorage.html";document.body.append(iframe);//Pass token to iframesetTimeout(function () { iframe.contentWindow.postMessage(token, "http://app1.com");}, 4000);setTimeout(function () { iframe.remove();}, 6000);//Bind an event listener to the HTML loaded by this iframe. When the event is triggered, write the received token data to localStoragewindow.addEventListener ('message ', function (event) { localStorage.setItem('token', event.data)}, false);

The frontend writes the same Token to LocalStorage in multiple domains through iframe+postMessage(). Each time before sending a request to the backend, the frontend will actively read the Token from LocalStorage and carry it in the request, thus realizing that the same Token is shared by multiple domains.

This implementation is completely controlled by the front-end, requires little back-end involvement, and also supports cross-domain.

Thank you for reading, the above is "Linux single sign-on three ways to achieve what are the full content, learn friends to quickly operate it. I believe that Xiaobian will definitely bring you better quality articles. Thank you for your support of the website!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.