Definition/Requirements

Single sign-on (SSO) allows users to log in only once and have direct access to all trusted systems.

Dealing with problems/technical background

• Traditional single-system Tomcat login

  • At login, the user information is saved in the Session object
  • On exit, delete user information from session

• Sessions are not shared among multiple systems

The solution

Design scenario

Scenario 1 Internal subsystems log in to each other

All front-end service requests are intercepted by the authentication center (some are implemented through the gateway and authentication service), and the authentication center determines whether to log in.

If the login succeeds, you can directly access the corresponding subsystem without further login.

If you have not logged in, the login page is displayed.

Similar to spring microservices architecture, gateway unified authentication.

Scenario 2 The current system is integrated with a third-party system

On a third-party system, click the button to jump to the current system.

Scenario 3 The independent authentication center manages multi-system login

The most typical and commonly used

The login process

System 1 Login:

• The user enters the user name and password to submit a login application

• The authentication center verifies user information, creates a global session between the user and the authentication center, and creates an authorization token

• The authentication authority redirects the original requested address with the token (System 1)

• System 1 gets the token and goes to the certification authority to verify that the token is valid

• Certificate authority verifies the token, returns valid, registers system 1

• System 1 uses this token to create a session with the user, called a local session, that returns the protected resource

System 2 Login:

• Users access protected resources in system 2

• System 2 finds that the user does not log in, switches to the authentication center, and sets its own address as a parameter

• The authentication authority finds that the user is logged in and jumps back to the address of system 2 with the token attached

• System 2 gets the token and goes to the certification authority to verify that the token is valid

• Certificate authority verifies the token, returns valid, registers system 2

• System 2 uses this token to create a local session with the user and return the protected resource

Logged-in Process

The procedure for verifying login failure and token expiration is as follows:

• When a user accesses the protected resources of system 1, system 1 finds that the user does not log in, switches to the authentication center, and sets its own address as a parameter

• If the authentication center finds that the user has not logged in, the user is directed to the login page

Log Out Process

The procedure for logging out is as follows:

• The client initiates a request to exit the system

• System 1 obtains the token based on the session ID established between the user and system 1 and sends a deregistration request to the authentication center

• The certification authority validates the token, destroys the global session, and extracts all system addresses registered with the token

• The ca issues a deregistration request to all registration systems

• Each registration system receives the cancellation request from the authentication center and destroys the local session

• The authentication center directs the user to the login page

Global sessions and local sessions have the following constraints

• If a local session exists, a global session must exist

• Global sessions exist, but local sessions do not necessarily exist

• Global session destruction, local session must be destroyed

Scenario 4 Logging In to the current system using a third-party System Account

Like the scene three

Reference documentation

• Single sign-on (SSO) is enough
• What is Single Sign-on (SSO)
• Single sign-on principle and implementation