Continue to introduce the first part of the "Single sign-on and permission management" series: the essence of single sign-on and permission management. The first two articles introduce sessions, cookies and HTTP redirection . With them, browsers can automatically Interactive to achieve automatic login.
This article introduces single sign-on. The so-called single sign-on means that users only need to log in in one place. When accessing other related systems, they do not need to log in repeatedly, and they automatically log in implicitly, so that the experience will be better.
Mainly from the following aspects:
- A common interaction process
- Common Single Sign-On Protocols
- Summary of key issues
A common interaction process
In our project, the CAS protocol is used to implement single sign-on. Let's take the implementation in the project as an example. Let's first look at the interaction process and have a basic understanding of its implementation.
There are 2 systems. System A is the "customer service desk", which is mainly used by customer service. It can chat with visiting users in real time and answer users' questions. System B is a "work order system". For questions that cannot be answered, the customer service will create a work order, and people with a higher level or high degree of relevance will see the work order for processing.
The customer service hopes that after logging in to system A, there is no need to manually log in to system B, but a "single sign-on service" is needed to provide a unified login verification, coordinate the automatic login of system A and system B, define the service as service S, and its CAS The flow of the protocol scenario is as follows:
It took me a lot of time to draw the above picture. It looks complicated, but it's actually okay. I hope you take the time to read it. If you really understand the first two articles, this one is relatively simple.
Here is a summary of the process:
- The black circle and red characters indicate the generation and use of cookies, ABCDE means 5 cookies, 1 means generation, 2 means use;
- Whether it is system A or system B, if there is no jessionid cookie, it will jump to service S. If it carries cookie1 (cookie generated after successful login), it will automatically log in without needing to log in. If it does not carry cookie1, it will jump to Go to the login page, after successful login, cookie1 will be set.
- cookie1 is kept in the browser and service S, indicating that the user has logged in;
- cookie2 and cookie4 are both temporary cookies, mainly to bring the service code to system A or system B. After getting the service code, request service S through the back-end for verification. After verification, the temporary cookie is invalid, mainly for security reasons. .
- Like the jessionid generated by our normal login, cookie3 and cookie5 are unique cookies for each subsystem;
If you have any questions, you can leave a message below and I will reply as soon as possible.
Common Single Sign-On Protocols
The above is one of the CAS protocols, and there are other protocols that can implement single sign-on, such as the protocols listed on the CAS official website:
These protocols have different applicable scenarios. For example, many websites support direct login using QQ, WeChat, and Weibo. As long as your QQ, WeChat, and Weibo logins are logged in, you don’t need to log in repeatedly. The OAuth protocol can be used to better achieve this. Scenes.
These protocols are described separately later.
Summary of key issues
Regardless of the protocol, an intermediate system is required to manage the authentication and authorization in a unified manner. In addition, cookie management and security issues need to be considered.
The following article will introduce what security problems may exist, and how to solve the security problems, how to manage cookies and sessions, will focus on the introduction of each specific protocol.
