Understanding Single Sign‑On (SSO) and CAS Authentication Flows

SSO Introduction

As enterprises grow, a large system may contain many subsystems, forcing users to log in repeatedly; SSO offers a unified login method for such application groups.

Background

Web systems evolve from a single system into an application group composed of many subsystems.

The complexity should be handled internally by the system, not by the user, so a single login/logout suffices.

SSO Definition

SSO (Single sign‑on) is an access‑control method for many interrelated but independent software systems.

It allows a user to log in once and access all mutually trusted applications.

Analogy: buying a single amusement‑park ticket lets you ride all attractions without repurchasing at each ride.

Analogy to each subsystem authentication, see diagram

Three Types of SSO

All subsystems under the same site.

All subsystems under the same top‑level domain (uses cookie domain sharing).

Subsystems under different top‑level domains (requires CAS – Central Authentication Service).

CAS (Central Authentication Service)

What is CAS

CAS – Central Authentication Service – is an open‑source project initiated by Yale University to provide a reliable SSO solution for web applications. It implements the same cookie‑session pattern as typical SSO systems.

First visit APP1

User accesses APP1 and is redirected to the CAS Server for authentication.

CAS Server validates credentials, creates a session, issues a TGT and an ST, and writes a cookie for the current domain.

APP1 receives the ST, validates it with the CAS Server, and obtains a login state.

APP1 writes its own session (JSESSIONID) and returns the protected content.

First visit APP2 (after APP1 login)

User accesses APP2, which redirects to the CAS Server.

CAS Server uses the existing TGT to generate an ST for APP2.

APP2 validates the ST with the CAS Server and receives a login state.

APP2 creates its own session and serves the requested page without requiring a new login.

CAS Tickets

TGT – Ticket‑Granting Ticket, stored in the CAS Server session after user authentication.

TGC – Ticket‑Granting Cookie, set in the response header to identify the user (sessionId).

ST – Service Ticket, issued based on the TGT for a specific service (application).

CAS SSO & SLO

Single Sign‑On (SSO)

User accesses APP1, which redirects to the CAS Server for authentication.

CAS Server presents a login page; after successful login it creates an SSO session and sets CASTGC.

APP1 receives a Service Ticket (ST) and validates it with the CAS Server.

CAS Server returns a successful response; APP1 creates its own session (JSESSIONID) and serves the content.

Subsequent requests to APP1 include the JSESSIONID cookie for verification.

Single Logout (SLO)

APP1 initiates logout, redirects to CAS with a service query and CASTGC.

CAS Server invalidates the TGT and retrieves all associated STs.

CAS Server calls each registered logoutUrl, sending a logoutRequest containing the ST.

APP1 and APP2 receive the logoutRequest, locate the corresponding session by ST, delete it, and complete logout.

Note: The remainder of the original page contains promotional links, community invitations, and copyright statements, which are not part of the technical explanation.