Shulou(Shulou.com)06/02 Report--

This article shows you what the XXL-SSO distributed single sign-on framework is. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

I. introduction 1.1 Overview

XXL-SSO is a distributed single sign-on framework. You only need to log in once to access all trusted applications.

With "lightweight, distributed, cross-domain, Cookie+Token support, Web+APP support" and other features. It is now open source and can be used out of the box.

1.2 Features

Simplicity: API is intuitive and simple, and can be used quickly.

Lightweight: low environment dependence, low deployment and access costs

Single sign-on: you only need to log in once to access all trusted applications.

Distributed: applications connected to SSO authentication center to support distributed deployment

Both HA:Server and Client support cluster deployment to improve system availability

Cross-domain: support cross-domain applications to access SSO authentication center

Cookie+Token supports both Cookie-based and Token-based access, and both provide Sample projects

Both Web+APP support: support Web and APP access

Real-time: login and logout status of the system, real-time sharing of all Server and Client

CS structure: based on CS structure, including Server "certification authority" and Client "protected applications"

Remember the password: when you do not remember the password, if you close the browser, the login state is invalid; when you remember the password, the login state is automatically extended, which can be extended indefinitely in principle on the basis of the custom extension time.

Path exclusion: supports customization of multiple exclusion paths and supports Ant expressions. Used to exclude paths that SSO clients do not need to filter

1.3download source code warehouse address source code warehouse address Release Download https://github.com/xuxueli/xxl-ssoDownloadhttps://gitee.com/xuxueli0323/xxl-ssoDownload1.4 environment

JDK:1.7+

Redis:4.0+

Mysql:5.6+

2. Quick start (based on Cookie) 2.1: system database initialization 2.2: source code compilation-xxl-sso-server: central authentication service, supporting cluster;-xxl-sso-core:Client side dependence;-xxl-sso-samples: single sign-on client access example project -xxl-sso-web-sample-springboot: based on Cookie access method, for browsers to access. Springboot version-xxl-sso-token-sample-springboot: based on Token access method, often used in scenarios where Cookie cannot be used, such as APP and Cookie are disabled. Springboot version 2.3 deployment "Certification Authority (SSO Server)" project name: xxl-sso-server configuration description

Configuration file location: application.properties

…… / / redis address: such as "{ip}", "{ip}: {port}", "{redis/rediss}: / / xxl-sso: {password} @ {ip}: {port:6379} / {db}"; multiple address comma separates the xxl.sso.redis.address=redis://127.0.0.1:6379// login validity window. Default is 24H. When the login validity window is halfway through, it will automatically postpone a cycle. Xxl.sso.redis.expire.minite=14402.4 deployment "single sign-on client access sample project" project name: xxl-sso-web-sample-springbootmaven relies on com.xuxueli xxl-sso-core ${latest stable version} configuration XxlSsoFilter@Beanpublic FilterRegistrationBean xxlSsoFilterRegistration () {/ / xxl-sso, redis init JedisUtil.init (xxlSsoRedisAddress); / / xxl-sso, filter init FilterRegistrationBean registration = new FilterRegistrationBean (); registration.setName ("XxlSsoWebFilter"); registration.setOrder (1) Registration.addUrlPatterns ("/ *"); registration.setFilter (new XxlSsoWebFilter ()); registration.addInitParameter (Conf.SSO_SERVER, xxlSsoServer); registration.addInitParameter (Conf.SSO_LOGOUT_PATH, xxlSsoLogoutPath); return registration;} configuration instructions

Configuration file location: application.properties

…… # xxl-sso (SSO configuration on Client side) # address of SSO Server Certification Authority (it is recommended to configure CA in the form of domain name. For more information, please refer to section "2.5" to modify the configuration of domain name in host file) xxl.sso.server= http://xxlssoserver.com:8080/xxl-sso-server##### logs out and logs in to path. The value is the relative path of Client application, excluding Path. Multiple settings are allowed and Ant expressions are supported. Used to exclude paths xxl-sso.excluded.paths=### redis/ / redis address, like "{ip}", "{ip}: {port}", "{redis/rediss}: / / xxl-sso: {password} @ {ip}: {port:6379} / {db}"; Multiple "," separatedxxl.sso.redis.address=redis://xxl-sso:password@127.0.0.1:6379/02.5 verification "

Environment preparation: start Redis, initialize Mysql table data

Modify the Host file: access the authentication authority by domain name to simulate cross-domain and online real environment

# add the following content 0127.0.0.1 xxlssoserver.com127.0.0.1 xxlssoclient1.com127.0.0.1 xxlssoclient2.com to the host file

Run "xxl-sso-server" and "xxl-sso-web-sample-springboot" respectively

1. The address of SSO Certification Authority:

Http://xxlssoserver.com:8080/xxl-sso-server

2. Client01 application address:

Http://xxlssoclient1.com:8081/xxl-sso-web-sample-springboot/

3. Client02 application address:

Http://xxlssoclient2.com:8081/xxl-sso-web-sample-springboot/

SSO login / logout process verification

Normally, the login process is as follows:

1. Access "Client01 App address" and automatically redirect to "SSO Certification Authority address" login interface

2. After successfully logging in, redirect will automatically return to the "Client01 application address" and switch to the logged-in state.

3. If you visit the "Client02 App address", you will automatically switch to the logged-in status without logging in.

Normally, the logout process is as follows:

1. If you access the "logout login path" configured by "Client01 Application address", you will automatically redirect to "SSO Certification Authority address" and log out the login status automatically.

2. If you access the "Client02 App address", the login status will be logged out automatically.

3. Quick start (based on Token) 3.1 "Certification Authority (SSO Server)" Construction

After the "Certification Authority" has been successfully built, the API API is provided for Token login by default as follows:

1. Login API: / app/login

Code:200 indicates success and other failures

Msg: error prompt

Data: login user's sso sessionid

Username: account number

Password: account number

Parameter: POST parameter

Response: JSON format

2. Log out API: / app/logout

Code:200 indicates success and other failures

Msg: error prompt

SessionId: login user's sso sessionid

Parameter: POST parameter

Response: JSON format

3. Login status check API: / app/logincheck

Code:200 indicates success and other failures

Msg: error prompt

Data: login user information

Userid: user ID

Username: user name

SessionId: login user's sso sessionid

Parameter: POST parameter

Response: JSON format

3.2 deploy "single sign-on client access sample project" (Token method) project name: xxl-sso-token-sample-springboot

You can refer to "Section 2.4" to deploy "single sign-on client access sample project". The only difference is that the "XxlSsoFilter" of web application is replaced by "XxlSsoTokenFilter" of app application.

3.3Verification (simulates the interface that requests Token access to SSO)

Environment preparation: start Redis, initialize Mysql table data

Modify the Host file: access the authentication authority by domain name to simulate cross-domain and online real environment

# add the following content 0127.0.0.1 xxlssoserver.com127.0.0.1 xxlssoclient1.com127.0.0.1 xxlssoclient2.com to the host file

Run "xxl-sso-server" and "xxl-sso-token-sample-springboot" respectively

1. The address of SSO Certification Authority:

Http://xxlssoserver.com:8080/xxl-sso-server

2. Client01 application address:

Http://xxlssoclient1.com:8082/xxl-sso-token-sample-springboot/

3. Client02 application address:

Http://xxlssoclient2.com:8082/xxl-sso-token-sample-springboot/

SSO login / logout process verification

Normally, the login process is as follows:

1. After obtaining the account password entered by the user, request the login interface of SSO Server to obtain the user sso sessionid; (reference code: TokenClientTest.loginTest)

2. After you have successfully logged in, you need to store the sso sessionid actively and set it in the parameter Header for subsequent requests.

3. At this point, use sso sessionid to access the interfaces provided by the protected "Client01 Apps" and "Client02 Apps", and the interfaces are returned normally. (reference Code: TokenClientTest.clientApiRequestTest)

Normally, the logout process is as follows:

1. Request the logout API of SSO Server and log out the login voucher sso sessionid; (reference code: TokenClientTest.logoutTest)

2. After a successful logout, sso sessionid will fail globally.

3. At this point, if you use sso sessionid to access the interfaces provided by the protected "Client01 Apps" and "Client02 Apps", the interface request will be intercepted, indicating that you are not logged in and the status code 501 will be returned. (reference Code: TokenClientTest.clientApiRequestTest)

Fourth, the overall design 4.1 function positioning

XXL-SSO is a distributed single sign-on framework. You only need to log in once to access all trusted applications. With the help of XXL-SSO, we can quickly realize single sign-on in distributed system.

4.2 Core concept description SSO Server central authentication service, supporting cluster; SSO Client access to Client application of SSO authentication center; SSO SessionId login user session ID,SSO login successfully assigned to users; SSO User login user information, corresponding to SSO SessionId; 4.3 login process analysis

When a user accesses restricted resources on the Client application, he / she will automatically redirect to SSO Server to enter the unified login interface.

After a successful login, the user will be assigned a SSO SessionId and the redirect will be returned to the source client application, along with the assigned SSO SessionId.

Verify that the SSO SessionId is correct in the SSO Filter on the client side, and write the SSO SessionId to the cookie under the domain name on the Client side of the user's browser.

SSO Filter verifies that SSO SessionId is passed, and request for release of restricted resources

4.4 Analysis of the logout process

When the user and the Client application request to log out of the Path, it will automatically destroy the global SSO SessionId from redirect to SSO Server to achieve global destruction.

Then, when accessing any Client application protected by SSO, SSO Filter will intercept the request and redirect it to SSO Server's unified login interface.

4.5 based on Cookie

Login voucher storage: after a successful login, the user's login credentials are automatically stored in the browser Cookie

Client verification of login status: check whether the request Cookie contains user login credentials.

System role model:

SSO Server: authentication center, which provides user login, logout and login status check and other functions.

Client application: client-side Web application protected by SSO to provide services for user browser access

User: the user who initiated the request and accessed it using a browser.

4.6 based on Token

Storage of login credentials: after successful login, login credentials (xxl_sso_sessionid=xxx) are obtained, which need to be stored actively, such as in localStorage and Sqlite

Client verification of login status: check whether the request Header parameter contains the user login credential (xxl_sso_sessionid=xxx); therefore, you need to set the login credential in the Header parameter when sending the request.

System role model:

SSO Server: authentication center, which provides user login, logout and login status check and other functions.

Client applications: client-side Web applications protected by SSO to provide interface services for user requests

User: the user who initiated the request, such as using Android, IOS, desktop client, etc., to request access.

4.7 request processing for unlogged-in status

Based on Cookie, no login status request:

Page request: redirect to SSO Server login interface

JSON request: returns unlogged JSON format response data

Code:501 error code

Msg:sso not login.

Data format:

Based on Token, no login status request:

Returns JSON format response data that is not logged in

Code:501 error code

Msg:sso not login.

Data format:

4.8 automatic extension of login status

Custom login validity window is supported. The default is 24H. When the login validity window is more than halfway through, it will automatically extend one cycle.

4.9 remember the password

When the password is not remembered, the login state is invalid when the browser is closed; when the password is remembered, the login state is automatically extended, which can be extended indefinitely in principle on the basis of the custom extension time.

4.10 path exclusion

Custom paths exclude Path, allow multiple settings, and support Ant expressions. Used to exclude paths that SSO clients do not need to filter

The above is what the XXL-SSO distributed single sign-on framework is, and have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.