How CAS Enables Secure Single Sign-On: From Cookie SSO to Central Authentication

1. Review of Cookie‑Based Single Sign‑On

Cookie‑based SSO stores the encrypted username and password in a cookie; when a user visits a site, a filter checks the cookie and logs the user in, giving the impression of a single login.

The drawbacks are repeated transmission of credentials (increasing theft risk), inability to work across domains, and duplicated login logic across multiple sites such as www.qiandu.com and mail.qiandu.com.

2. Unified Authentication Center Concept

Analogous to a cafeteria where a ticket replaces cash, the improved solution centralizes authentication in an independent service (the passport server). Users are redirected to http://passport.com for login, and the passport server records the session.

The flow is:

User accesses www.qiandu.com; filter redirects unauthenticated users to passport.com.

Passport.com receives credentials, stores login info in a server‑side session.

Passport.com issues a special credential (ticket) to the browser, which forwards it to www.qiandu.com.

www.qiandu.com validates the ticket with passport.com and, upon success, grants access.

3. Yale‑Developed CAS (Central Authentication Server)

CAS introduces a dedicated authentication center (cas.qiandu.com) and multiple user web services.

The authentication center provides login services via the CAS framework; user web projects only need to configure CAS client filters in web.xml.

4. Detailed CAS Login Process

4.1 First Visit to www.qiandu.com

1. User requests www.qiandu.com; AuthenticationFilter (org.jasig.cas.client.authentication.AuthenticationFilter) checks login status and redirects to cas.qiandu.com with a service parameter.

2. Browser follows the 302 redirect to cas.qiandu.com.

3. CAS server presents a login page.

4. User submits credentials; CAS validates them and issues a Service Ticket (ST) plus a CASTGC cookie.

5. Browser redirects back to www.qiandu.com with the ST.

6. www.qiandu.com validates the ST with CAS; upon success, the user gains access.

CASTGC stores a Ticket‑Granting Cookie; the corresponding Ticket‑Granting Ticket (TGT) allows CAS to issue STs without re‑authenticating.

4.2 Second Visit to www.qiandu.com

Because the session already contains user information, the CAS client filter passes the request without additional validation.

4.3 Accessing mail.qiandu.com

1. User requests mail.qiandu.com; the site redirects to the CAS server.

2. Browser sends the existing CASTGC cookie; CAS uses the associated TGT to issue a new ST.

3. Browser follows the redirect back to mail.qiandu.com with the ST.

4. mail.qiandu.com validates the ST with CAS, establishes a session, and grants access.

5. Summary

The complete CAS login process—from initial redirection, ticket issuance, validation, to subsequent seamless accesses—has been outlined. Future work will cover practical CAS integration into projects.