Introduction to single sign on system

Background analysis

In the traditional login system, each site implements its own special login module. The login status of each site does not recognize each other, and each site needs to log in manually one by one. For example:

Such a system is also called multipoint login system. The application is relatively cumbersome (each time you access the resource service, you need to log in again for authentication and authorization). At the same time, the repetition of system code is also relatively high. Thus, the single sign on system was born.

Overview of single sign on system

Single Sign On (abbreviated as Single Sign On) SSO ). That is, multiple sites share one authentication and authorization server. After logging in at any one site, users can access all other sites without logging in. Moreover, each site can interact directly through the login status. For example:

Solution design of single sign on system

• Solution 1: after the user logs in successfully, store the user login status in the redis database, for example:

Note: in this scheme, after the user logs in successfully, a token will be generated based on UUID, and then bound with the user information and stored in the database When subsequent users access resources, they query the user status from the database based on the token. This method has average performance because it needs to store and query the user status based on the database

• Solution 2: after the user logs in successfully, store the user information in the token, and then write it to the client for storage. (this design scheme)

Note: in this scheme, after the user logs in successfully, a token will be generated based on JWT technology, and the user information can be stored in this token When accessing resources, subsequent users parse the token content, check the login status and permission information, and do not need to access the database again

Preliminary design of single sign on system

Service design

Based on the business description in the single sign on system, the preliminary service architecture design is carried out, as shown in the figure:

 

Among them, services are divided based on business. System services only provide basic data (such as user information, log information, etc.), authentication services (auth) are responsible for verifying user identity, comparing passwords, and resource services represent some business services (such as my orders, my collections, etc.)

Engineering structure design

Based on the division of services, the design engineering structure is as follows:

 

SSO parent project creation and initialization

Create parent project

Step 1: create a parent project, for example:

 

Step 2: delete the src directory of the parent project (optional).

Initial configuration of parent project pom file

Initialize pom file contents, for example:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.jt</groupId>
    <artifactId>02-sso</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!--maven Parent project pom Sub modules are generally defined in the file,
    Management of dependent versions required in subprojects,Public dependencies, and the packaging method of the parent project is generally pom mode-->

    <!--First step: Define the version management of the core dependencies in the subproject(be careful,Just version management)-->
    <dependencyManagement>
        <dependencies>
            <!--spring boot Core dependent version definition(spring Official definition)-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.3.2.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

            <!--Spring Cloud Microservice specification(from spring Official definition)-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Hoxton.SR9</version>
                <type>pom</type><!--If scope yes import,type Must be pom-->
                <scope>import</scope><!--Introducing third-party dependent version design-->
            </dependency>

            <!--Spring Cloud alibaba Dependent version management (Refer to official instructions)-->
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>2.2.6.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <!--Step 2: Add the required public dependencies of the subproject-->
    <dependencies>
        <!--lombok rely on,If necessary in the subproject lombok,No need to import-->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <scope>provided</scope><!--provided Indicates that this dependency is only valid at compile time-->
        </dependency>
        <!--Unit test dependency,When unit test is required in subproject,There is no need to introduce this dependency again-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope><!--test Indicates that only test Use this dependency under the directory-->
            <exclusions>
                <exclusion><!--Eliminate unnecessary dependencies-->
                    <groupId>org.junit.jupiter</groupId>
                    <artifactId>junit-jupiter-engine</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <!--Other dependencies...-->
    </dependencies>
    <!--Step 3: Define the unified compilation and running version of the current project module and subproject-->
    <build><!--Project build configuration,We are based on maven Complete the compilation of the project,test,Packaging and other operations,
    All based on pom.xml Complete the operation of this column,However, the compiled and packaged configurations are written to build element
    Internal,The specific compilation and packaging configuration,Need again plugin To achieve,plugin Element is not required,maven
    There is a default plugin to configure,Common plug-ins can be viewed in the local library-->
        <plugins>
            <!--adopt maven-compiler-plugin Plug in settings item
            Unified jdk Compile and run versions-->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <!--If the local library does not have this version,A red font error will appear here-->
                <version>3.8.1</version>
                <configuration>
                    <source>8</source>
                    <target>8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>