Introduction to Single Sign-On (SSO) and CAS: Concepts, Scenarios, and Implementation

Single Sign‑On (SSO) allows a user to authenticate once with an identity provider and then access multiple trusted applications without re‑entering credentials, reducing login overhead and simplifying user management.

Traditional login requires separate authentication for each system, whereas SSO introduces a central authentication server that issues tickets or cookies to grant access across applications.

SSO is a popular enterprise integration solution; CAS (Central Authentication Service) is an open‑source, Java‑based framework that implements SSO, consisting of a CAS Server for authentication and CAS Clients embedded in protected applications.

CAS Server handles user verification and must be deployed independently, while CAS Client redirects unauthenticated requests to the server and processes the returned tickets.

Typical SSO scenarios include platforms like Sina Weibo and Sina Blog, where both services trust the same authentication center, allowing a user who logs into one service to seamlessly access the other without additional login steps.

There are three main SSO implementation patterns: (1) Same‑domain SSO, which relies on a single server without a dedicated SSO component; (2) Parent‑domain SSO, where cookies are set for a shared parent domain; and (3) Cross‑domain SSO (CAS), which uses a dedicated SSO server to share authentication across different domains.

Key CAS concepts include two REST‑style interfaces (/login for authentication and /logout for session termination) and three ticket types: TGT (Ticket‑Granting Ticket) that represents a logged‑in session, TGC (Ticket‑Granting Cookie) which is the cookie storing the TGT, and ST (Service Ticket) issued for accessing a specific service.

The cross‑domain CAS implementation proceeds through a series of redirects: the user accesses application A, is redirected to the SSO server, logs in to obtain a TGT/TGC, receives an ST, and is redirected back to A which validates the ST and creates a session; subsequent access to application B follows a similar flow, reusing the existing TGC to obtain a new ST without requiring another login.

For further reading, see the referenced blog posts that discuss CAS architecture and related authentication topics.