Basic concepts of SSO(Single Side on Single Sign-on)

  • Logins on one system can be done on multiple other systems without logins. To optimize resource utilization and reduce coupling
  • In simple terms, single sign-on (SSO) means that in multiple systems, a user only needs to log in once, and each system can perceive that the user has logged in.
  • LLDB: For example, taobao and Tmall are two different systems, but when you log in to Tmall, Taobao will automatically log in.

SSO architecture

  1. Authentication Center (provides user authorization for login)
  2. User and account system, user data acquisition interface (unified management of user accounts, interface to provide user data)
  3. Client module (used when business systems integrate SSO)
  4. Token

SSO authentication process

  1. Request resources
  2. Token validation – Presence – Validation valid – Valid/invalid – Valid direct access to resources/invalid Re-authentication to obtain a new token

| | user authorization access to resources

  • It can be divided into 4 steps

    • Check whether the token exists

    • Check whether the token is valid

    • Token authentication

    • Token generation process

  • It can be roughly divided into three modules
    • SSOserver Authentication center
      1. Verifying token Validity
      2. The login page is displayed, and the token is successfully generated
      3. Provide logout, single point exit function
    • SSOClient Client module
      1. Intercepts the request, extracts the token, and presents it to the certification authority for verification
      2. The authentication succeeds, and the resource information is obtained
      3. The user is redirected to the login page
    • SSO User & Manager Accounts and account management system
      1. Provides user login and logout operation logs
      2. Provides user information viewing, management, and statistics functions
      3. Synchronize user information for service systems supported by interfaces
      4. Add and modify user information for specific service systems that are supported by interfaces

Central Authentication Service (CAS) principle

When we think of single sign-on, we should think of CAS, which is the logic used for single sign-on. So let me tell you what CAS is.

  • Here we give examples:
  1. First of all, we have A system A: www.java1y.com which integrates the authentication service
  2. At this point we need a system B: www.java2y.com due to business needs
  3. But we found that the logon logic of system A and system B was the same and the database was the same, so there was no need to maintain both systems for login authentication.
  4. Then we can consider separating the logon logic of the original system A and B from the logon logic of the original system A and B and maintaining the logon logic separately to form A service called authentication center: www.sso.com, plus the new system A:www.java3y.com and system B: www.java4y.com stripped of the logon authentication service, as shown in the figure below:

  • And then we actually have a CAS. Then his logic goes something like this:
  1. First the user wants to access system A:www.java3y.comFor limited resources (such as shopping cart functionality), system A finds that the user is not logged in and redirects to the SSO authentication authority with its own address as A parameter, requesting the following address:
    • www.sso.com?service=www.java3y.com

The SSO authentication center detects that the user does not log in and directs the user to the login page. Then the user authenticates the login. After the authentication succeeds, the user establishes a global session with the authentication center (generates a token, writes it into a Cookie, and stores it in the browser).

After the authentication is successful, the system redirects to system A and carries the token to system A: – www.java3y.com? Token = XXXXXXX

Then, system A goes to the authentication center with the obtained token to verify whether the token is correct. If the token is correct, system A and the user establish A partial Session. By then, system A and the user have logged in.

  1. If the user wants to access system B at this point:www.java4y.comFor limited resources (such as order information), system B will verify whether the user is logged in. If the user is not logged in, system B will redirect the user to the authentication center with its own address as follows:
    • www.sso.com?service=www.java4y.com

Note: In fact, the request of system B is accompanied by the cookie in system A, so the authentication center can know through the cookie that it has established A session with system A before, and then the authentication center will redirect back to system B with token: – www.java4.com? Token = XXXXXXX Then, system B checks whether the token is valid at the center of the People’s Bank of China. If the token is valid, system B establishes a local Session with the user. At this point, system B and user are already logged in.

Cross-domain SSO

  1. Solution:
    • jsonp
    • Cors has compatibility issues, which are distinguished by the browser’s determination to return headers

Principles of cross-domain SSO:

  1. The flow chart

  1. Cross-domain Cookie reads and writes

    • Call the Cookie writing method in the server with a request (jSONP script request, either with cORS method, or with a local proxy)

    • Some browsers have third-place restrictions on third-party cookies, which can be removed by setting P3P

      • P3P is configured in the return header (see BD for details)

    • Cross-domain information transfer is realized through URL parameters