background

In the early stage of enterprise development, enterprises use very few systems, usually one or two, each system has its own login module, operation personnel log in with their own account every day, very convenient. However, with the development of enterprises, more and more systems are used. When operating different systems, operation personnel need to log in several times, and the account of each system is different, which is very inconvenient for operation personnel. So, it occurs to me that I can log in to one system without logging in to other systems. This is the problem single sign-on addresses.

Single sign-on (SSO) is the full English name of Single Sign On. In multiple applications, you only need to log in once to access other trusted applications.

As shown in the figure, there are four systems, Application1, Application2, Application3, and SSO. Application1, Application2, and Application3 have no login module, but SSO has only the login module and no other service module. When Application1, Application2, and Application3 need to log in, SSO will jump to the SSO system. The SSO system logs in, and other applications log in as well. This fits perfectly with our definition of single sign-on (SSO).

The technical implementation

Before we talk about the technical implementation of single sign-on (SSO), let’s talk about the general login authentication mechanism.

As is shown in the figure above, we access an application in Browser, which requires login. After filling in the user name and password, we complete login authentication. At this point, we mark the login status of the user as yes in the session and write a Cookie in the Browser, which is the unique identity of the user. Next time we visit this application, the request will carry this Cookie, and the server will find the corresponding session according to this Cookie, and judge whether the user logs in or not. If no special configuration is made, the Cookie is named jsessionID and the value is unique on the server.

Single sign-on in the same domain

Generally, an enterprise has only one domain name. Secondary domain names are used to distinguish different systems. For example, we have a domain name named “a.com” and two business systems named “App1.a.com” and “App2.a.com”. We want to do single sign-on (SSO), need a login system, called: sso.a.com.

We just logged in at sso.a.com, app1.a.com and App2.a.com. Through the login authentication mechanism above, we can know that the login in sso.a.com is actually recorded in the session of the server side of sso.a.com, while the Cookie is written in the Browser side of sso.a.com. So how do we get App1.a.com and App2.a.com to log in? There are two questions:

  • Cookie cannot be cross-domain. The domain attribute of our Cookie is sso.a.com, which cannot be taken when sending requests to App1.a.com and App2.a.com.
  • Sso, APP1, and App2 are different applications. Their sessions are stored in their own applications and are not shared.

So how do we solve these two problems? For the first question, after sso login, the Cookie domain can be set to the top domain, i.e..a.com, so that all sub-domain systems can access the Cookie in the top domain. When we set cookies, we can only set the top field and our own field, not other fields. For example, we cannot set cookies for the domain of Baidu.com in our own system.

Now that we’ve solved the Cookie problem, let’s look at the session problem. When we log in to the SSO system and then access APP1, the Cookie is also brought to the Server of APP1. How can the Server of APP1 find the Session corresponding to this Cookie? In this case, sessions are shared between the three systems, as shown in the figure. There are many solutions for sharing sessions, such as Spring-Session. So problem number two is solved.

Single sign-on in the same domain is implemented, but it is not true single sign-on.

Single sign-on in different domains

Single sign-on in the same domain exploits the Cookie top domain feature. What if it’s a different domain? What if cookies are not shared between domains?

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

The figure above is the standard process of CAS official website, and the specific process is as follows:

  1. The user accesses the APP system, which requires login, but the user is not logged in.
  2. Switch to the CAS server, that is, SSO login system. The CAS server in the following figure is called SSO system. The SSO system is not logged in, and the user login page is displayed.
  3. After a user enters the user name and password, the SSO system authenticates the user, writes the login status to SSO session, and writes the Cookie in the SSO domain in Browser.
  4. After the SSO system logs in to the system, a Service Ticket (ST) is generated. Then, the SYSTEM switches to the APP system and passes the ST to the APP system as a parameter.
  5. After the APP system gets the ST, it sends a request to SSO from the background to verify whether the ST is valid.
  6. After the authentication passes, the APP system writes the login status into the session and sets the Cookie in the APP domain.

At this point, cross-domain single sign-on is complete. When we visit the APP system in the future, the APP is logged in. Next, let’s look at the flow when accessing the APP2 system.

  1. When a user accesses app2, the user does not log in to app2 and switches to SSO.
  2. Since SSO is already logged in, re-login authentication is not required.
  3. SSO generates an ST, and the browser jumps to the APP2 system and passes the ST to App2 as a parameter.
  4. App2 gets the ST and accesses SSO in the background to verify whether the ST is valid.
  5. After successful authentication, App2 writes the login status to session and cookies to the App2 domain.

In this way, app2 system does not need to go through the login process, it is already logged in. SSO, APP, and App2 are in different domains, so it’s ok that the session between them is not shared.

Some students asked me that when THE SSO system logs in and jumps back to the original business system with a parameter ST, the business system needs to use ST to access SSO again for verification. I think this step is a bit redundant. He thinks that after SSO login authentication is passed, the user information is returned to the original service system through the callback address, and the original service system directly sets the login status. In this way, the process is simple and the login is completed. Isn’t it good?

In fact, this problem is very serious, if I do not log in SSO, but directly in the browser to type the address of the callback, with forged user information, is the business system also considered logged in? This is terrible.

conclusion

The process of single sign-on (SSO) is all covered, and the principle is clear. Summary of a single sign-on to do things:

  • Single sign-on (SSO) ensures the security of user resources in each service system.
  • The information each business system gets is whether or not this user can access my resources.
  • In single sign-on (SSO), resources are on the side of each business system, not on the side of SSO. After a user provides a username and password to the SSO server, the business system is unaware of this. SSO randomly gives the business system an ST, so the business system cannot determine whether the ST is forged by the user or really valid. Therefore, I need to take the ST to the SSO server and ask whether the ST given to me by the user is valid, so THAT I can allow the user to access it.

reference

  1. Single sign-on (SSO) is enough
  2. Cas Protocol Flow Chart