Continuing the first part of the “Single Sign-on and Permission Management” series: The nature of single sign-on and permission management, the first two articles covered sessions and cookies and HTTP redirects, enabling browsers to automatically interact with multiple systems for automatic login.
A complete writing program for the series, see: Series Overview
This article introduces single sign-on (SSO), the so-called single sign-on (SSO), which means that users only need to log in in one place, and do not need to log in again when accessing other related systems, so that the experience is better.
Mainly from the following aspects:
- A common interaction flow
- Common single sign-on protocols
- Summary of Key issues
A common interaction flow
In our project, CAS protocol is used to realize single sign-on. The following takes the implementation of the project as an example to first look at its interaction process and get a basic understanding of the existing situation.
There are two systems. System A is the “customer service workstation”, which is mainly used by customer service. It can chat with visiting users in real time and answer their questions. System B is the “work order system”. For the problem that cannot be solved, the customer service will create a work order, and people with higher level or higher relevance will see the work order and process it.
After logging in to system A, the customer service does not need to manually log in to system B, but needs A single sign-on service to provide unified login authentication and coordinate the automatic login of system A and system B. The service is defined as service S. The flow of the CAS protocol is as follows:
It took quite a while to draw the picture above, but it looks complicated, but I hope you take the time to read it, and if you really understand it in the first two articles, this one will be relatively easy.
To summarize the process:
- The black circle is red, indicating the generation and use of cookies. ABCDE represents 5 cookies, 1 represents the generation and 2 represents the use.
- Either system A or system B will jump to service S if there is no JessionID cookie. If there is cookie1 (the cookie generated after successful login), there is no need to log in and it will automatically log in. If there is no cookie1, it will jump to the login page. Cookie1 is set up after a successful login.
- Cookie1 keeps the browser and service S, indicating that the user is logged in;
- Cookie2 and Cookie4 are temporary cookies, which mainly bring the service code to system A or system B. After getting the service code, it requests service S at the back end for verification. After verification, temporary cookies become invalid, mainly for security reasons.
- Cookie3 and Cookie5, like the jessioniD generated by our normal login, are unique cookies to each subsystem;
If you have any further questions, please leave a comment below and I will reply as soon as possible.
Common single sign-on protocols
The preceding describes one CAS protocol. Other protocols can implement single sign-on (SSO), such as the protocols listed on the CAS official website:
These protocols have different applicable scenarios, such as a lot of websites support the use of QQ, wechat, Weibo direct login, as long as your QQ, wechat, Weibo record, do not have to repeat login, the use of OAuth protocol can be better to achieve this scenario.
These protocols are described separately below.
Summary of Key issues
Regardless of the protocol, an intermediate system is required to centrally manage authentication and authorization. In addition, cookie management and security issues need to be considered.
The following chapter will introduce the possible security problems. How to solve the security problems and how to manage cookies and sessions will be highlighted in the introduction of each specific protocol.
Series index:
- Session and cookie introduction
- HTTP redirection
- Introduction to single sign-on
- Cookie Security
- Rights Management
