In the past, I have a little understanding of single sign-on, but it is not very systematic. In addition, I have been doing the related requirements of single sign-on recently, and I feel that I do not have a detailed understanding of some key concepts. This article intends to systematically sort out my understanding of single sign-on.

Why single sign-on?

At first, when we just learned the SSM framework in the Field of Java Web, we mainly produced XX management system, which is generally oriented to enterprise users. However, enterprise users usually do not only use one system. If the enterprise develops well, the enterprise will gradually introduce other systems. For example, at the very beginning of the introduction of office automation system, used to achieve reimbursement, entry and other automation. This enterprise belongs to the manufacturing enterprise in order to improve quality management, and introduced the quality management system. With the popularity of online office, this enterprise also purchased a special system for approval and reimbursement. With the development of the enterprise, this enterprise has more and more procurement systems:

It’s a headache for a person who has to use all of these systems at the same time, who has a lot of accounts, and he goes to work and he opens his browser, and he opens all of these systems at the same time, and he logs on. These accounts are troubling, we naturally have a vision, these systems are integrated in the office system, and then I just login office system, other systems like a button integration in office system page, I need to click the office when I was in quality management system of quality management system button to jump to the quality management system, No need to log in. Which brings us to Single sign-on, or Single Sign On.

A few problems with single sign-on

Let’s examine what you need to do when you jump from office to quality management to exempt logins. We can expect that different systems will have their own login authentication mechanisms, and it is not possible to leave the door open and turn all system login authentication off, because some of the manipulation of the software system revolves around the user. Some information can only be manipulated by certain users in the system.

Normal circumstances, the general design of the login operation is the user login page enter account and password, of course, now also support phone number login authentication code, system in the check and the user account and password input the correct circumstances, will be distributed to the client a token, you can understand this token to pass, the client again to access the server resources, In the request, the token issued by the server when the first successful login is placed. The server verifies the token and uses the token to determine who the current user is, and returns data to the client. However, different systems issue tokens in different ways, including session-cookie mode and JWT mode.

In addition to different system table structure design is not the same, the password is not the same in the two sets of system, certification system is different also, we are unlikely to do other systems used in every system of the data for the record, and in the office system to the quality management system, server returned to the front office system account and password, The front end automatically fills the quality management system account number and password, which is obviously not safe, people who understand a little Web system can easily intercept the password. The final problem lies in the certification, we can think of each system has a certification office, different systems issue different passes, the two systems do not trust each other. So we naturally wonder if there is a unified certification center? Each system trusts the token issued by the unified authentication center. After receiving the token, the client can log in once in one system and be exempted from logging in in other systems. This requires each application to support the certification authority’s token, which is to supplement the original login with one authentication method, or to adopt the same method.

Several ways and problems of single sign-on

The above discussion can be thought of as a way to implement single sign-on, not close to the technology. If the discussion is closer to the technology, we can implement single sign-on without authentication authority. Let’s review the previous login is realized by Cookie and Session. The user and password are judged to be correct according to the information entered by the user. The user’s information is put into the Session, and the user’s information is obtained from the Session when the user accesses the server resources again. If no information about the user is obtained, the user is not logged in and the page is redirected to the login page.

For multiple systems, each system has an application server. Sessions are independent and cannot be shared. Do we perform global Session replication? In this way, complete synchronization is somewhat distributed, and the network is not completely reliable. If you pursue strong consistency, performance will be affected. Put Session information in Redis, which is a good suggestion, for your own internal development system, you can solve the Session sharing in this way. But for purchased systems, also access Redis? As powerful as Redis is, there is no performance problem with putting sessions into Redis without restraint.

Another common way is to develop a certification center, procurement system to transform itself to support certification center issued by the token, the user login in the request, check not logged in, jump to the application center, with its own address when you in the center of the jump certification, certification center certification through, after return to token, jump back, You can log in. At the next request, the token returned by the authentication center is brought along, and the interceptor obtains the token to determine whether to log in or not. Related user information is also put into Redis by the unified authentication Center. This is another way to implement single sign-on.

When it comes to single sign-on (SSO), the Central Authentication Service(CAS) is not the abbreviation for Compare and swap. What the hell is that?

Central Authentication Service (CAS) is a single sign-on protocol for the World Wide Web. It is intended to allow a user to access multiple applications while providing credentials (such as a user name and password) to the authentication server only once. This not only eliminates the need for users to re-authenticate when logging into Web applications, but also prevents these applications from accessing sensitive information such as passwords. “CAS” also refers to the software package that implements the protocol. — Wikipedia

This feels like the certification authority we discussed above. Yes, the centralized certification service is not just a protocol, but also an open source project that supports multiple languages and multiple protocols. To put it simply, it is a WAR package that provides authentication service. We can access our business system with a little modification, and let our multi-system support single sign-on. As an example of A centralized authentication service network, suppose we now have two systems, A and B, with addresses www.aaa.com and www.bbb.com. Authentication center: www.sso.com. The user requests system A, and system A finds that the current user has not logged in, so it redirects to the authentication center. The address bar is as follows:

  • www.sso.com? name = www.aaa.com

When the authentication center finds that the user has not logged in, it will direct the user to the login page. When the user enters necessary information to log in, it will establish a global session with the authentication center (generate a token and write it into the Cookie. If you do not understand the token, it can be interpreted as a pass. Note that the domain name in the Cookie is sso.com.

The authentication authority then redirects back to system A and carries the token back to system A. The redirected address is as follows:

  • www.aaa.com?token=xxxxxx

System A then goes to the authentication center to verify whether the Token is valid and correct. If yes, A Session is created and the Token is entered into the system. User A has successfully logged in to system A. Suppose that A user in system A wants to log in to system B, and system B finds that user A has not logged in to me, and then redirects to the authentication center, taking its own address as A parameter, and requests the following address:

  • www.sso.com?name=www.bbb.com

When A user logs in to system A through the authentication center, the Cookie is already saved in the browser. In this case, the authentication center obtains the Token from the Cookie from system B and then redirects the Cookie back to system B to carry the Token back to system B. The redirection address is as follows:

  • www.sso.com?token=xxxxx

The user then goes to the authentication center to verify the validity of the token. If the token is valid, system B allows the user to log in and creates a Session. This process is not obvious to the user. At this point, the user has logged in to system B.

To summarize

In short, the sharing of user information and login status between multiple systems is the problem to be solved by single sign-on. The authentication information of one system after login needs to be obtained by another system. In this regard, we can put the login information into Redis to realize information sharing, or we can set up a certification center for unified verification.

The resources

  • Cookie, Session, Token, JWT? zhihu

  • What is single sign-on (SSO) java3y

  • Detail SSO SSO