[JAVA EE] Detailed explanation of single sign-on

About the Author

Table of contents

1 Overview

SSO, authenticate once and then have access to all subsystems. Obviously, SSO is just a concrete goal. Currently, in order to achieve single sign-on and unified authentication, the industry has proposed a series of methods. For example, there is a mature component CAS, which can be used directly out of the box. It provides the services of the authentication center and also provides the dependencies of the client. You can directly start the authentication center and introduce the dependency configuration on the client to use it. For example, there are standard protocols such as oauth2.0, etc., which stipulate the entities and steps in the entire process.

In fact, in general, single sign-on is nothing more than issuing a credential to users after logging in, and then relying on this credential to verify permissions. This credential can be a cookie, a session, a token, a jwt, etc. The specific one you want to use depends on your business scenario. Currently, token is the most commonly used one in the industry. This article will not discuss those complicated and rigid processes, such as which status codes are returned at which steps. Bloggers have always believed that single sign-on is an idea, and rigid processes are meaningless.

The following is a general process for single sign-on.

When logging in for the first time:

The request will go to the authentication server for authentication. If it is found that there is no login, it will return to the login page for the user to log in. After the user logs in, a certificate will be returned to the user, and the authentication center will also save a copy.

Subsequent visits:

Subsequent visits will carry the credentials to the authentication center for authentication. The authentication center will compare the credentials to confirm whether the user has access rights.

What should be noted here is that generally the logic of authenticating to the authentication center is implemented on each service, and a series of logic for authentication success and failure must be processed. The reason for this is that you can identify those operations on the service that require logging in. For example, some operations can be performed without logging in. For example, you do not need to log in to browse Taobao, but you need to log in to purchase goods. It is hoped that all requests will not be sent to the authentication center without thinking, so as to form such a logical structure:

Thereby reducing the pressure on the authentication center.

2. Implementation plan

There are two architectures for implementation:

Decentralized authentication
Centralized authentication

2.1. Decentralized authentication

Decentralized authentication means that authentication capabilities are distributed to various applications. There is no need for a separately deployed authentication center. All applications can maintain the same credential storage medium. Generally, a cache such as redis is used as the storage medium for this credential. Each application performs its own authentication, which means that each application must implement a complete set of authentication logic, along with accompanying logic processing of success and failure. I guess at this time many students thought of directly adding spring security to each service. It is indeed possible to do this. Using spring security can save us a lot of coding and just use the capabilities of the framework to perform authentication verification.

The blogger has an article to explain in detail how to use spring security:

Detailed explanation of Spring Security-CSDN blog

Of course, there are other ways besides using spring security, such as:

Interceptor using spring mvc
Using servlet filters

etc.

In decentralized authentication, there is a problem that needs attention. The login standards must be consistent. That is to say, the authentication center must provide a login page for users who have not logged in to log in for the first time. The data parsing logic after the user submits a login request , the data organization method of user information, these contents must be consistent in each application. For the sake of standardization, the best way is to put them together for unified maintenance, extract the entire authentication capability separately and make it a dependency, and introduce a unified dependency for each application for configuration and use. I'm just afraid that everyone will write their own thing and then it will fork.

2.2. Centralized authentication

Centralized authentication means putting authentication together, for example using:

CAS
gateway.

As mentioned before, centralized authentication will put pressure on the authentication center. Why do we still talk about centralized authentication here? That's because if you use a gateway, all traffic will go through the gateway, and there is no way to spread the pressure. Secondly, in a centralized solution, the authorized nodes are generally optimized for throughput and can withstand Larger throughput.

1.CAS

CAS is an open source project initiated by Yale University, aiming to provide a reliable single sign-on method for Web application systems. There is an independently deployed authentication center (cas server) in CAS. By introducing dependencies on the client and configuring it, the client can become a cas client, and the client and server rely on credentials for authentication. The blogger will publish a separate article on the specific use of cas later. The relevant information on the Internet is also available on the Internet. Students who need to use it now can search it themselves.

2.Gateway

If we are using a microservice architecture with a gateway, we can use the request classification and interception processing capabilities of gateways such as gateways to perform unified authentication.

Take gateway as an example. Gateway uses one route to process a type of requests. A reason assertion is composed of a filter and the assertion is responsible for judging the request. Only requests with a true judgment result will be released. Therefore, we can authenticate through custom assertions. For custom assertions, you can check the relevant implementation in the open source community or official documents. Of course, with custom assertions, you can also use spring security on the gateway to implement authentication. The specific solution depends on the needs of the business scenario.