How Does CAS Single Sign-On Work? A Deep Dive into SSO Authentication Flow

1. Unconventional Start

1. Background Introduction

Single Sign‑On (SSO) allows a user to log in once and access all trusted applications.

The CAS framework (Central Authentication Service) implements SSO.

2. Analysis of a Common CAS Diagram

Note: Original source omitted.

Structurally, CAS consists of two parts: CAS Server and CAS Client, which must be deployed independently and handle user authentication. CAS Client protects web resources via a filter, intercepting each request. If the request lacks a Service Ticket, the client redirects the user to the CAS Server (Step 2). The user authenticates (Step 3), the server generates a random Service Ticket, caches it, and redirects back to the client with the ticket. The ticket cannot be forged, and the client validates it with the server, establishing the user's identity. All CAS interactions use SSL to protect ST and TGC. The protocol involves two redirects, but the ticket validation between client and server is transparent to the user. Summary of the process: Access service: SSO client requests a protected resource. Redirect for authentication: client redirects the user to the SSO server. User authentication: the user logs in. Issue ticket: the SSO server creates a Service Ticket. Validate ticket: the server verifies the ticket and allows access. Transmit user info: the server sends authentication results to the client.

2. Further Exploration in the Cloud

Source for this section: "SSO CAS Series – Implementing an SSO Authentication Server" (specific sections highlighted in red are the author's questions).

1. Login Information Transmission

First login flow:

User accesses System A, which checks for a session and finds none, so no ticket is present.

System A redirects to the authentication center to obtain a global ticket.

The authentication center presents a login page; after successful login, it redirects back to System A with a Service Ticket.

System A receives the ticket, validates it with the CAS server, and confirms the user is logged in.

System A returns the protected resource to the user.

Already logged‑in user accesses System B:

User requests a protected resource on System B; no local session is found.

System B redirects to the authentication center, which detects the existing global session.

The authentication center issues a temporary ticket and redirects to System B.

System B validates the ticket, confirming the user is logged in.

System B returns the protected resource.

2. Login State Determination

After logging into the authentication center, a global session (TGT) is created. Local applications establish a partial session that depends on the global session; when the global session ends, local sessions must also end.

When a user accesses an application, the presence of a local session indicates a logged‑in state, avoiding a round‑trip to the authentication center. If no local session exists, the application redirects to the authentication center to check the global session and, if valid, creates a new local session.

3. Logout

When a user logs out from one system, all other subsystems should also reflect the logged‑out state. The application ends its local session and notifies the authentication center.

The authentication center terminates the global session and informs all participating subsystems to destroy their local sessions.

Logout flow:

Client sends a logout request to Application A.

Application A ends its local session and notifies the authentication center.

Application A returns a response to the client.

The authentication center notifies all applications that the user has logged out.

3. Clarifying All Highlighted Questions

1. Detailed Answers to Highlighted Questions

1) How does System A detect that a request requires login and redirect to the authentication center?

Answer: System A (CAS client) checks the browser's cookies for a JSESSION ID. If present, the user is considered logged in; otherwise, the request is redirected for authentication.

2) What information or URL does System A send when redirecting to the authentication center?

Answer: Assuming System A runs at http://a:8080/ and the CAS server at http://cas.server:8080/, the redirect URL becomes http://cas.server:8080/?service=http://a:8080/, passing the original service URL as a parameter.

3) How is the authentication token attached to the redirect back to System A after a successful login?

Answer: The browser is redirected to http://a:8080/?ticket=ST-XXXX-XXX, sending the Service Ticket as the ticket query parameter.

4) How does System A verify the token to prove the user is logged in?

Answer: System A extracts the ticket value from the URL, sends it to the CAS server for validation, receives user information upon successful verification, and creates a session (identified by a cookie) for the user.

5) How does the authentication center determine that the user is already logged in when accessing System B?

Answer: After logging into System A, the user obtains a Ticket Granting Ticket (TGT) stored in a Ticket Granting Cookie (TGC) on the browser. When System B redirects to the CAS server, the server reads the TGC; if present, it knows the user is already authenticated and issues a Service Ticket for System B.

6) What actions do each system perform during logout?

Answer: The authentication center clears the global session (TGT) and removes the TGC cookie. Each client application (e.g., System A, System B) clears its local session and deletes its JSESSION cookie.

2. Annotated Login Flow Diagram for System A

Source: https://blog.csdn.net/javaloveiphone/article/details/52439613