A, description,

Single sign-on (SSO), as the name implies, allows you to log in to multiple application systems only once to access other trusted application systems without multiple logins. This article mainly introduces the implementation principle of single sign-on (SSO) in the same domain and cross-domain scenarios, and uses Spring Security to implement a simple cross-domain SSO client.

 

Two, principle description

Single sign-on is mainly realized based on shared cookies. The following two scenarios are respectively introduced in the same domain and cross domain. How to realize shared cookies

2.1. Same-domain single sign-on

Application scenario: All enterprise systems use the same level-1 domain name and are distinguished by different level-2 domain names.

For example, the company has a first-level domain name of zlt.com, and we have three systems: portal system (sso.zlt.com), application 1(App1.zlt.com) and application 2(app2.zlt.com). Single sign-on between systems needs to be implemented. The implementation architecture is as follows:

Core Principles:

  1. Portal systemSet up theCookie 的 domainIt’s a level 1 domain name which iszlt.com, so that you can share the portalCookieTo all users of this domain name (xxx.zlt.com) systems
  2. useSpring SessionTechnology shared across all systemsSession
  3. So as long asPortal systemAfter login, regardless of the jumpApplication 1orApplication 2, all through the portalCookieIn thesessionIdreadSessionThe login information implementation inSingle sign-on (sso)

 

2.2. Cross-domain SINGLE sign-on

System domain names are different between single sign-on systems, such as third-party systems. Because domain names are different, cookies cannot be shared. Therefore, a single authorization service (UAA) is required for unified login, and single sign-on (SSO) is implemented based on cookies of shared UAA.

For example, there are two systems: Application 1(webApp.com) and Application 2(zlt.com), which need to implement single sign-on. There is also a UAA authorization center (SSO.com), which has the following architecture:

Core Principles:

  1. Procedure Access the system. 1 If you do not log in, switch to the UAA system to request authorization
  2. inUAA systemThe domain namesso.comEnter the user name and password in the login address
  3. After successful loginUAA systemSave the login information toSession, and write the domain in the browser assso.com 的 Cookie
  4. Access the system. 2 Check whether you have logged in to the UAA system and request authorization
  5. As is the jump toUAA systemThe domain namesso.comUnder, so can through the browser UAACookiereadSessionThe previous login information is completeSingle sign-on (sso)

 

2.3. Cross-domain single sign-on process based on Oauth2

Oauth2 authorization code mode is not introduced here, find information to understand

 

Implementation of Spring Security

Oauth2 Single sign-on requires the authorization center to complete the unified login/authorization logic

For details about the UUA unified authorization center based on Spring Security, see gitee.com/zlt2000/mic…

Each system itself (SSO client) also needs to implement the following logic:

  1. Interception requests determine login status
  2. withUAA Authorization CenterthroughOauth2 Authorization code modeInteractive complete login/single sign-on
  3. Saves user login information

The above logic can be implemented with a single @enableoAuth2SSO annotation

SpringBoot configuration is as follows:

The following figure shows how the @EnableoAuth2SSO annotation interacts with the UAA authorization center in Oauth2 authorization code mode to complete single sign-on (SSO) when accessing the SSO client

Follow steps 1 to 5 of sso System 2 in the single point sequence diagram above

PS: What if the system is not using Spring Security? The understanding principle is self-fulfilling

 

4. Demo download address

Gitee.com/zlt2000/mic…

Scan code attention has surprise!