How CAS Enables Secure Single Sign-On: Architecture, Protocols, and Best Practices

CAS Introduction

What is CAS?

CAS (Central Authentication Service) is an open‑source, enterprise‑grade project initiated by Yale University to provide a reliable Web Single Sign‑On (SSO) solution.

CAS started in 2001 and became an official JA‑SIG project in December 2004.

Main Features

Open‑source, multi‑protocol SSO solution (Custom Protocol, CAS, OAuth, OpenID, RESTful API, SAML 1.1, SAML 2.0, etc.).

Supports various authentication mechanisms: Active Directory, JAAS, JDBC, LDAP, X.509 certificates.

Security policy based on tickets.

Authorization control over which services may request and validate Service Tickets.

High availability via TicketRegistry implementations (BerkeleyDB, Ehcache, JDBC, JBoss TreeCache, JPA, Memcache, etc.).

Client support for Java, .NET, PHP, Perl, Apache, uPortal, and others.

SSO Principles

What is SSO?

Single Sign‑On allows a user to log in once and gain access to all trusted applications without re‑authenticating.

SSO Roles

The typical SSO ecosystem includes three roles: Users, Web applications, and a single SSO authentication server.

Implementation Principles

All authentication occurs at the SSO server.

The server informs web applications whether the current user is authenticated.

Web applications must trust the SSO server (single‑sign‑trust).

Common Implementation Methods

Shared cookies (now deprecated due to security concerns).

Broker‑based approach (central authentication server, e.g., Kerberos, Sesame).

Agent‑based approach (proxy program that translates authentication between client and server, e.g., SSH).

Token‑based methods (SecureID, WebID, etc.).

Gateway‑based methods.

SAML‑based methods (standardized SSO protocol).

CAS Architecture

Structure

CAS consists of a CAS Server and CAS Clients.

CAS Server

The server handles user authentication, processes credentials, and must be deployed independently.

CAS Client

The client protects resources, redirects unauthenticated requests to the CAS Server, and typically operates as a filter.

Basic Protocol Flow

User accesses a protected service.

Client redirects the user to the CAS Server.

User authenticates.

CAS Server issues a Service Ticket (ST).

Client validates the ST with the server.

Upon successful validation, the server returns user information to the client.

Proxy Mode

In proxy mode, a CAS Client can obtain a Proxy‑Granting Ticket (PGT) to act on behalf of the user when accessing downstream services.

Security Considerations

CAS security relies on SSL and secure cookies.

TGC/PGT Security

Protecting the Ticket‑Granting Cookie (TGC) and Proxy‑Granting Ticket (PGT) is critical; if compromised, an attacker can impersonate the user across all services.

ST/PT Security

Service Tickets are single‑use.

Tickets expire after a configurable short period (default 5 minutes).

Tickets are generated from high‑entropy random numbers.