Let's talk about CAS authentication in single sign-on (SSO)

Introduction to SSO

background

• With the development of enterprises, a large-scale system may contain n multiple subsystems. When users operate different systems, they need to log in multiple times, which is very troublesome. We need a new login method to realize the login of multi-system application groups. This is single sign-on .
• The web system has developed from a single system to an application group composed of multiple systems , and the complexity should be borne by the system rather than the user. No matter how complex the web system is, it is a unified whole for users, that is to say, users accessing the entire application group of the web system is the same as accessing a single system, and logging in/out only once is enough.

Definition of SSO

• SSO (Single sign-on) is single sign-on, a method of providing access control for many interrelated but independent software systems

• SSO (Single sign-on) is one of the more popular solutions for enterprise business integration. The definition of SSO (Single sign-on) is that in multiple application systems, users only need to log in once to access all mutually trusted application systems

  Take the amusement park pass as an example:

We only need to buy a pass once, and we can play all the facilities in the amusement park without having to buy a new ticket on the roller coaster or Ferris wheel. Here, buying a ticket is equivalent to login authentication, an amusement park is equivalent to a company using a set of SSO, and various amusement facilities are equivalent to various products of the company.

Analogy to each subsystem authentication, as shown in the figure

Three types of SSO

• Each subsystem is under the same site

• Each subsystem is under the same top-level domain name

  The single sign-on under the same site and the same top-level domain takes advantage of the shared feature of the cookie top-level domain. At present, the data stack only needs to log in once on the UIC login page to jump between sub-applications. This operation comes from setting the domain in the cookie as the top-level domain name.

• Each subsystem belongs to a different top-level domain

  If they belong to different domains, cookies between different domains are not shared. How to do? Next, let's talk about the CAS (Central Authentication Service) process, which is a standard process for single sign- on.

CAS (Central Authentication Service)

what is CAS

Central Authentication Service —— Central Authentication Service is an enterprise-level, open source project initiated by Yale University, aiming to provide a reliable SSO solution for Web application systems. It is just one of the SSO solutions. Its process is actually the same as the Cookie-session mode. Single sign-on means that each subsystem has a complete set of Cookie-session mode, plus a set of Cookie-session mode. SSO system .

Visit APP1 for the first time:

1. When users access APP1 , they will be redirected to CAS Server when they need to log in
2. Account and password authentication is performed on the CAS Server , the CAS Server will save the session , and generate a sessionId and return it to the SSO Client. The SSO Client writes the Cookie of the current domain, and issues 1 ST to APP1 according to the TGT .
3. APP1 carries ST to request verification from CAS Server
4. After the CAS Server verification is successful, it returns the login status to the APPI server
5. The APPI server writes the login status to the session and generates a sessionId and returns it to the APPI Client
6. Then do the login authentication, that is, the authentication under the same domain

Visit APP2 for the first time:

1. The user accesses the system APP2 , and when he jumps to the SSO to log in, he finds that the SSO has already logged in, then the SSO generates an ST , and carries the ST into the APP2
2. APP2 carries ST to request verification from CAS Server
3. After the CAS Server verification is successful, it returns the login status to the APP2 server
4. The APP2 server writes the login status to the session and generates a sessionId and returns it to the APPI Client
5. In this process, APP2 does not need to go through the login process

CAS ticket

TGT

The CAS Server creates a TGT , which is stored in the Session of the CAS Server and signed according to the user information.

TGC

At the same time as the TGT is created, the TGC is generated. Set TGC through the set-cookie field of the response header of the CAS Server to uniquely identify the user identity ( sessionId ) ST

ST

The ST issued according to the TGT is the ticket issued by CAS for the user to access a service

CAS Single Sign On (SSO) & Single Sign Out (SLO)

Single Sign-On (SSO)

Visit APP1 for the first time:

1. When accessing the APP1 service address, the APP1 request fails the authentication and is redirected to the CAS Server address.
2. Visit the CAS Server address, send an authentication request, and bring a cookie .
3. CAS Server recognizes that the user has no cookie information and is not logged in, and returns the CAS login page address.
4. The user enters the correct account password, the CAS Server user authentication is passed, and the SSO Session is created.
5. Redirect back to the service address of APP1 , and create a CASTGC in the cookie , TGC contains Ticket (TGT) , TGT is the key of SSO Session .
6. Access the service address of APP1 and bring the ST , and the client gets the ST to authenticate to the CAS Server .
7. CAS Server authentication is successful and returns response information to APPI
8. After APPI gets a successful response, it sets the Session , redirects back to the address of APP1 , and sets the Cookie JSESSIONID .
9. APPI initiates a request with the information in the cookie , in which JSESSIONID is used to determine the session information corresponding to the current user and send it to the client for verification.
10. The client uses JSESSIONID to verify the data stored in the Session .
11. The verification is passed, the correct content is returned, and APP1 is displayed

Second visit to APP1:

1. APPI initiates a request and brings the JSESSIONID in the cookie to the APPI server.
2. The APPI server uses JSESSIONID to verify the data stored in the Session .
3. The verification is passed, the correct content is returned, and APP1 is displayed.

In the case of successful login of APP1, access APP2 for the first time:

1. When accessing the APP2 service address, the APP2 request fails the authentication and is redirected to the CAS Server address.
2. Access the CAS Server address, send an authentication request, and bring the TGT information.
3. The CAS Server uses the TGT to find the SSO information for authentication.
4. After the authentication is passed, the generated ticket ST is redirected to the service address of APP2 .
5. The APP2 service carries the ST for authentication to the CAS Server .
6. CAS Server authentication succeeds and returns a response passed by the client.
7. After the client gets a successful response, it sets the Session , redirects to the address of APP2 , and sets the Cookie MOD_AUTH_CAS_S .
8. APP2 initiates a request, brings MOD_AUTH_CAS_S in the cookie , and sends it to the client for verification.
9. The client uses MOD_AUTH_CAS_S to verify the data stored in the Session .
10. The verification is passed, the correct content is returned, and APP2 is displayed.

Official timing chart

Single Sign Out (SLO)

1. After the APP1 platform requests to log out, first carry the service field in the query to redirect the CAS logout address
2. User carries service query field and CASTGC request to CAS Server
3. CAS Server finds TGT information according to CASTGC , deletes TGT and completes CAS cancellation
4. CAS Server can get all associated STs in TGT , find the corresponding application registration information according to ST , call logoutUrl in it, wrap ST into logoutRequest and send it to APP1
5. APP1 finds ST according to logoutRequest , finds the value with ST as the key in Session , deletes it, and clears the login status
6. APP1 successfully logged out
7. APP2 finds ST according to logoutRequest , finds the value with ST as the key in Session , deletes it, and clears the login status
8. APP2 successfully logged out