Single Sign On (Single Sign On) is enough to read this article

[[347603]]

background
In the early stages of enterprise development, the company used very few systems, usually one or two. Each system had its own login module, and operators logged in with their own accounts every day, which was very convenient.

However, as the company develops, the number of systems used increases. When operating different systems, operators need to log in multiple times, and each system has a different account. This is very difficult for operators.

So, it is very inconvenient. So, I thought, can I log in to one system without logging in to other systems? This is the problem that single sign-on is going to solve.

Single Sign On, or SSO, is short for Single Sign On. It means that in multiple application systems, you only need to log in once to access other mutually trusted application systems.

image

As shown in the figure, there are 4 systems, namely Application1, Application2, Application3, and SSO. Application1, Application2, and Application3 do not have login modules, while SSO only has login modules and no other business modules. When Application1, Application2, and Application3 need to log in, they will jump to the SSO system. After the SSO system completes the login, other application systems will also log in. This fully meets our definition of single sign-on (SSO).

Technical Implementation
Before talking about the technical implementation of single sign-on (SSO), let's first talk about the common login authentication mechanism.

As shown in the figure above, we access an application in the browser. This application requires login. After we fill in the username and password, we complete the login authentication. At this time, we mark the login status as yes (logged in) in the session of this user, and write a cookie in the browser. This cookie is the unique identifier of this user. The next time we access this application, the request will carry this cookie. The server will find the corresponding session based on this cookie and determine whether the user is logged in through the session. If no special configuration is made, the name of this cookie is jsessionid, and the value is unique on the server.

Single sign-on in the same domain
Generally, an enterprise has only one domain name, and uses secondary domain names to distinguish different systems. For example, we have a domain name called a.com, and two business systems: app1.a.com and app2.a.com. If we want to do single sign-on (SSO), we need a login system called sso.a.com.

As long as we log in to sso.a.com, app1.a.com and app2.a.com will also log in. Through the above login authentication mechanism, we can know that when we log in to sso.a.com, the login status is actually recorded in the session of the sso.a.com server, and the cookie is written under sso.a.com on the browser side (Browser). So how can we let app1.a.com and app2.a.com log in? There are two questions here:

• Cookies cannot cross domains. The domain attribute of our cookie is sso.a.com, which cannot be included when sending requests to app1.a.com and app2.a.com.
• sso, app1 and app2 are different applications. Their sessions exist in their own applications and are not shared.

So how do we solve these two problems? For the first problem, after SSO login, the domain of the cookie can be set to the top domain, that is, .a.com, so that all subdomain systems can access the top domain cookie. When we set cookies, we can only set the top domain and our own domain, and cannot set other domains. For example: we cannot set cookies for the domain of baidu.com in our own system.

The cookie problem has been solved. Now let's look at the session problem. We have logged in to the sso system. When we visit app1, the cookie is also brought to the server of app1. How can the server of app1 find the session corresponding to this cookie? Here we need to share the sessions of the three systems, as shown in the figure. There are many solutions for sharing sessions, such as Spring-Session. This solves the second problem.

Single sign-on in the same domain is achieved, but this is not true single sign-on.

Single sign-on under different domains
Single sign-on in the same domain makes use of the top-domain feature of cookies. What if it is in different domains? Cookies are not shared between different domains, what should I do?

Here we have to talk about the CAS process, which is the standard process for single sign-on.

cas_flow_diagram

The above picture is the standard process on the CAS official website. The specific process is as follows:

1. The user accesses the app system, which requires login, but the user is not logged in now.
2. Jump to CAS server, which is the SSO login system. From now on, we will call the CAS server in the figure the SSO system. The SSO system has not been logged in yet, and the user login page pops up.
3. The user fills in the user name and password. After the SSO system performs authentication, the login status is written into the SSO session and the cookie under the SSO domain is written into the browser.
4. After the SSO system login is completed, a ST (Service Ticket) will be generated, and then jump to the app system, and the ST will be passed to the app system as a parameter.
5. After the app system obtains the ST, it sends a request to SSO from the background to verify whether the ST is valid.
6. After verification, the app system writes the login status to the session and sets the cookie under the app domain.

At this point, cross-domain single sign-on is complete. When we access the app system in the future, the app will be logged in. Next, let's take a look at the process of accessing the app2 system.

1. The user accesses the app2 system. The app2 system is not logged in and jumps to SSO.
2. Since SSO has already logged in, there is no need to log in again for authentication.
3. SSO generates ST, the browser jumps to the app2 system, and passes ST as a parameter to app2.
4. App2 obtains the ST and accesses SSO in the background to verify whether the ST is valid.
5. After successful verification, app2 writes the login status to the session and writes a cookie under the app2 domain.

In this way, the app2 system does not need to go through the login process, it is already logged in. SSO, app and app2 are in different domains, and there is no problem with not sharing the session between them.

Some students asked me that after logging in to the SSO system, when jumping back to the original business system, there is a parameter ST, and the business system needs to use ST to access SSO again for verification. They think this step is a bit redundant. He wants to return the user information to the original business system through the callback address after the SSO login authentication is passed, and the original business system directly sets the login status. This process is simple and the login is completed. Isn't it great?

In fact, this problem is very serious. If I do not log in to SSO, but directly type the callback address in the browser with forged user information, will the business system also think that I am logged in? This is very scary.

Summarize

All the processes of single sign-on (SSO) have been introduced, and the principles are clear to everyone. To summarize what single sign-on needs to do:

• Single sign-on (SSO system) is to ensure the security of user resources of each business system.
• The information obtained by each business system is whether this user can access my resources.
• With single sign-on, resources are on the business system side, not on the SSO side. After the user provides the SSO server with the username and password, the business system does not know about this. SSO gives the business system a random ST, and the business system cannot be sure whether the ST is forged by the user or is really valid, so it has to take the ST to the SSO server to ask whether the ST given by the user is valid. Only if it is valid can I allow the user to access.