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

This article mainly explains "what are the ways to achieve single sign-on". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what are the ways to achieve single sign-on?"

Preface

The login function is usually implemented based on Cookie in the BPUBG S system. When the user logs in successfully, the login status is usually recorded in Session, or a Token is issued to the user. Either way, some information (Session ID or Token) needs to be saved on the client side, and the client is required to carry them in each subsequent request. In such a scenario, using Cookie is undoubtedly the most convenient, so we usually save the ID or Token of Session to Cookie. When the server receives the request, it verifies whether the user is logged in by verifying the information in Cookie.

Single sign-on (Single Sign On, SSO) means that in multiple application systems under the same account platform, users only need to log in once to access all the applications that trust each other. For example, Baidu Tieba and Baidu Maps are two different application systems of Baidu. If a user logs in after Baidu Tieba, he does not need to log in again when he visits Baidu Maps, then it shows that single sign-on has been realized between Baidu Tieba and Baidu Maps.

The essence of single sign-on is to share login status in multiple application systems. If the user's login status is recorded in Session, to achieve shared login status, you must first share the Session. For example, you can serialize the Session to the Redis, let multiple applications share the same Redis, and directly read the Redis to get the Session.

Of course, this is not enough, because different application systems have different domain names, although Session is shared, but because Session ID is often stored in the browser Cookie, there is a scope restriction and cannot be transferred across domain names, that is to say, when a user logs in in app1.com, Session ID is automatically carried in the request header only when the browser accesses app1.com, and when the browser accesses app2.com. Session ID will not be taken there. The key to achieving single sign-on is how to make Session ID (or Token) shared across multiple domains.

Implementation method 1: parent domain Cookie

Before we go into concrete implementation, let's talk about the scope of Cookie.

The scope of Cookie is determined by both the domain attribute and the path attribute. The valid value of the domain attribute is the domain name / IP address of the current domain or its parent domain, and in Tomcat, the domain attribute defaults to the domain name / IP address of the current domain. The valid value of the path attribute is the path that begins with "/". In Tomcat, the path attribute defaults to the context path of the current Web application.

If you set the domain property of Cookie to the parent domain of the current domain, it is considered to be the parent domain Cookie. A feature of Cookie is that the Cookie in the parent domain is shared by the child domain, in other words, the child domain automatically inherits the Cookie in the parent domain.

Taking advantage of this feature of Cookie, it is not difficult to think of saving Session ID (or Token) to the parent domain. Yes, we just need to set the domain property of Cookie to the domain name of the parent domain (primary domain) and set the path property of Cookie to the root path, so that all child domain applications can access the Cookie. However, this requires that the domain name of the application system should be established under a common primary domain name, such as tieba.baidu.com and map.baidu.com, both under the primary domain name baidu.com, so they can achieve single sign-on in this way.

Summary: this method is relatively simple, but it does not support cross-primary domain names.

Implementation method 2: certification center

We can deploy a certification authority, which is an independent Web service dedicated to processing login requests.

The user uniformly logs in the authentication center. After the login is successful, the authentication center records the login status of the user and writes the Token to Cookie. Note that this Cookie is from the certification authority and the application system is not accessible. )

The application system checks whether there is a Token in the current request, and if not, it means that the user is not logged in in the current system, then the page will be redirected to the authentication authority. Because this operation will automatically bring the Cookie of the certification authority, the certification authority can know whether the user has logged in or not according to the Cookie. If the authentication authority finds that the user has not yet logged in, it will return to the login page and wait for the user to log in. If it is found that the user has already logged in, it will not let the user log in again, but will jump back to the target URL and generate a Token before the jump, which will be spliced after the target URL and passed 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 users from counterfeiting. After confirmation, the application system records the login status of the user, writes the Token to Cookie, and then releases it to this visit. Note that this Cookie is in the current application system and cannot be accessed by other applications. When the user visits the current application system again, it will automatically bring the Token, and the application system verifies that the Token finds that the user is logged in, so there will be nothing wrong with the authentication authority.

Here, by the way, are two open source implementations of certification authorities:

Apereo CAS is an enterprise single sign-on system, in which CAS means "Central Authentication Service". It was originally a laboratory project at Yale University, then transferred to JASIG, which changed its name to JASIG CAS, which was later incorporated into the Apereo Foundation and subsequently renamed Apereo CAS.

XXL-SSO is a simple single sign-on system, developed by Dianping engineer Xu Xueli personally, the code is relatively simple, there is no security control, so it is not recommended to be directly used in the project, listed here for reference only.

Conclusion: this kind of implementation is relatively complex, supports cross-domain, and has good expansibility, which is the standard practice of single sign-on.

Implementation method 3: LocalStorage cross-domain

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

The parent domain Cookie is indeed a good solution, but it does not support cross-domain. So is there any whimsical technique that allows Cookie to pass across domains?

Unfortunately, browsers have increasingly stringent cross-domain restrictions on Cookie. Chrome browsers also add a SameSite attribute to Cookie, which prohibits Cookie delivery of almost all cross-domain requests (except hyperlinks), and is allowed to accept Cookie from the server in AJAX cross-domain requests only if the HTTPs protocol is used.

However, when the front and rear ends are separated, we can choose not to use Cookie. We can choose to save the Session ID (or Token) in the browser's LocalStorage, so that the front end can actively transfer the LocalStorage data to the server each time it sends a request to the back end. All these are controlled by the front end, and all the back end needs to do is pass the Session ID (or Token) in the response body to the front end after the user has successfully logged in.

In such a scenario, single sign-on can be implemented at 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 be written to LocalStorage in multiple other domains by special means.

The key code is as follows:

/ / obtain token

Var token = result.data.token

/ / dynamically create an invisible iframe and load a cross-domain HTML in iframe

Var iframe = document.createElement ("iframe")

Iframe.src = "http://app1.com/localstorage.html";

Document.body.append (iframe)

/ / use the postMessage () method to pass token to iframe

SetTimeout (function () {

Iframe.contentWindow.postMessage (token, "http://app1.com");"

}, 4000)

SetTimeout (function () {

Iframe.remove ()

}, 6000)

/ bind an event listener in the HTML loaded by this iframe. When the event is triggered, the received token data is written to localStorage.

Window.addEventListener ('message', function (event) {

LocalStorage.setItem ('token', event.data)

}, false)

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

Summary: this implementation is completely controlled by the front end, requires almost no back-end participation, and also supports cross-domain.

Supplement: domain name rating

From a professional point of view (according to the definition in "computer network"), .com and .cn are first-level domain names (also known as top-level domain names), .com.cn and baidu.com are second-level domain names, sina.com.cn and tieba.baidu.com are third-level domain names, and so on, the N-level domain name is the direct subdomain name of the Nmuri level 1 domain name.

From the user's point of view, the primary domain name that can support independent filing is generally called the first-level domain name, such as baidu.com and sina.com.cn can be called the first-level domain name, the direct subdomain name established under the primary domain name is called the second-level domain name, such as tieba.baidu.com is the second-level domain name.

In order to avoid ambiguity, I will use "primary domain name" instead of "first-level domain name".

At this point, I believe you have a deeper understanding of "what are the ways to achieve single sign-on?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.