Introduction

Concepts

1. CAS

CAS (Central Authentication Service)
An open‑source Web SSO (Single Sign‑On) framework originated from Yale University.

2. SSO (Single Sign‑On)

Unify identity login verification for multiple web applications through one single endpoint.

• Features: Applications communicate over web protocols (HTTPS) with a global unified login entry point
• Plain explanation: Log in once at the authentication center within the same browser, and you can access all trusted services without repeated sign‑ins

3. Three Roles in the SSO Ecosystem

1. User: End‑user (web browser)
2. Web Applications (multiple business systems)
3. SSO Authentication Center (singleton)

4. Three Core Principles of SSO

1. All account login operations must be performed at the SSO authentication center;
2. The authentication center provides mechanisms to notify each web application whether the current user has been authenticated;
3. Pre‑established trust relationships exist between the authentication center and all business web applications.

Two Core Components

CAS Server (Authentication Server‑Side)

• Independently‑deployed web program, serving as the only authentication hub
• Responsibilities: Accept username and password credentials, validate user identity; issue tickets (Ticket), manage global session Cookie (TGC)

CAS Client (Embedded within each business system)

• Hosted inside each business web application, usually implemented as a Filter
• Responsibilities: Intercept requests for protected resources; redirect the browser to the CAS Server login page automatically when the user is unauthenticated

Workflow

1. User accesses resources on a business system → CAS Client intercepts the request and detects no Service Ticket present
2. The Client redirects the browser to the CAS Server login URL, passing along the current business system address (Service)
3. User submits username and password on CAS Server to complete authentication
   • Successful login: CAS Server sets a TGC (Ticket Granting Cookie) global session cookie in the browser
   • One‑time ticket generated: Service Ticket (ST)
4. CAS Server redirects the browser back to the business system URL with Ticket=xxx appended as a URL parameter
5. CAS Client on the business system makes a backend server‑to‑server call with Service address + Ticket to validate ticket legitimacy against CAS Server
6. CAS Server confirms valid ticket and returns user identity details such as username
7. Validation succeeds, business system creates local session and user can browse pages normally

Purpose of TGC: As long as the browser holds the TGC Cookie, subsequent visits to other CAS‑integrated systems skip the login prompt and single sign‑on happens automatically.

Introduction