Comprehensive Overview of Single Sign-On (SSO) and CAS Architecture
This article explains the fundamentals of Single Sign-On (SSO), why it is needed in distributed systems, details the components and workflow of the CAS (Central Authentication Service) implementation, and outlines common application scenarios such as e‑commerce, enterprise portals, education, and finance.
Single Sign-On (SSO), short for Single Sign-On, is an authentication and authorization mechanism that allows a user to access multiple applications or systems after a single login.
In large internet companies, many sub‑systems cooperate during a single transaction; requiring separate logins for each would overwhelm users and increase development complexity. SSO solves this by letting a user log in once and then access all trusted applications.
The typical SSO solution is the CAS (Central Authentication Service) system, an open‑source project initiated by Yale University to provide a reliable centralized authentication service for web applications.
CAS consists of three core components:
CAS Server – handles user authentication, generates and manages tickets (tokens), and returns them to applications after successful login.
CAS Client – integrated into each protected application; redirects unauthenticated users to the CAS Server and validates the returned ticket.
Service – represents a protected application; each service has a unique identifier that the CAS Server uses to issue tickets.
The SSO workflow using CAS works as follows:
User accesses Application A without a session; the app redirects the user to the CAS Server.
The CAS Server presents a login page; the user enters credentials.
After successful authentication, the CAS Server issues a ticket and redirects the user back to Application A.
Application A validates the ticket with the CAS Server and obtains user information.
When the same user later accesses Application B, the app redirects the user to the CAS Server, which directly returns a valid ticket without requiring another login.
Application B validates the ticket and grants access.
The user can continue to access additional trusted applications without re‑authenticating.
Common scenarios for CAS‑based SSO include:
1. E‑commerce platforms with multiple brand sites, providing seamless shopping across them.
2. Large enterprise intranets where employees need single‑click access to HR, finance, collaboration tools, etc.
3. Educational institution portals that unify campus portals and online learning platforms for students and staff.
4. Financial services offering various online products (banking, investment, insurance) that benefit from unified login.
At the end of the article, the author offers a free collection of over 300,000 words of original architecture material and a comprehensive Java interview question set, encouraging readers to add him on WeChat to receive the resources.
Mike Chen's Internet Architecture
Over ten years of BAT architecture experience, shared generously!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.