Understanding Single Sign-On (SSO) and CAS Authentication Flow

SSO Introduction

As enterprises expand, a large system may contain many subsystems, forcing users to log in repeatedly; Single Sign‑On (SSO) offers a unified authentication method so that a user logs in once to access the entire application suite.

Background

Web systems evolve from a single system to a group of multiple subsystems; the complexity should be handled internally by the system rather than by the user.

From the user's perspective the whole suite behaves like a single application—login and logout are required only once.

SSO Definition

SSO (Single Sign‑On) is a method of access control for many interrelated but independent software systems.

It allows a user to log in once and then access all trusted applications without re‑authenticating.

Analogy: buying a single amusement‑park ticket lets you ride all attractions without purchasing a new ticket at each ride; the ticket corresponds to login, the park to the SSO‑enabled company, and each ride to a product.

Three SSO Deployment Types

All subsystems reside under the same site.

All subsystems share the same top‑level domain – Cookie domain sharing is used (e.g., setting domain attribute to the top‑level domain).

Subsystems belong to different top‑level domains – Cookie sharing is impossible, so the Central Authentication Service (CAS) standard flow is required.

CAS (Central Authentication Service)

What is CAS?

CAS is an open‑source, enterprise‑grade project initiated by Yale University that provides a reliable SSO solution for web applications. It follows the same cookie‑session model as traditional SSO, but adds a central ticket‑granting mechanism.

CAS Login Flow – First Access to APP1

User visits APP1 ; the request is redirected to the CAS server for authentication.

CAS server validates credentials, creates a session, issues a Ticket‑Granting Ticket (TGT) and a Service Ticket (ST) , and writes a CAS cookie (CASTGC) to the browser.

APP1 receives the ST, forwards it to the CAS server for validation.

CAS server validates the ST and returns a login state to APP1.

APP1 creates its own session (JSESSIONID) and serves the protected resource.

CAS Login Flow – First Access to APP2 (after APP1 login)

User visits APP2 ; CAS detects an existing SSO session via the CASTGC cookie and directly issues an ST for APP2.

APP2 validates the ST with the CAS server and obtains a login state without prompting the user for credentials.

CAS Ticket Types

TGT (Ticket‑Granting Ticket) : stored on the CAS server, represents the user's authenticated session.

TGC (Ticket‑Granting Cookie) : the browser cookie that carries the TGT identifier.

ST (Service Ticket) : issued per service request, used by the service to verify the user with the CAS server.

CAS Single Sign‑Out (SLO) Process

User initiates logout from APP1; APP1 redirects to the CAS logout URL with a service parameter.

CAS receives the request together with the CASTGC cookie, locates the associated TGT, and deletes it.

CAS retrieves all STs linked to the TGT, contacts each registered service’s logoutUrl , and sends a logoutRequest containing the ST.

Each service (e.g., APP1, APP2) removes the session identified by the ST, completing the logout.

The article concludes with a call for discussion and a reminder that the technical content is for educational purposes.