CAS

What is CAS

CAS (Central Authentication Service) is an open-source single sign-on protocol based on HTTP. It requires every component in the protocol (CAS Server, CAS Client) to be accessible via a specific URI.

BambooCloud IDaaS supports acting as a CAS Server (identity authentication provider), enabling third-party applications (CAS Client) to read user account data through the CAS protocol and implement single sign-on.

We support CAS 1.0, CAS 2.0, and CAS 3.0 protocol versions.

Two Core Roles in the CAS Protocol

Role	Description	Example
CAS Server	Identity authentication provider, responsible for verifying user identity and issuing tickets	BambooCloud IDaaS authentication service
CAS Client	Resource provider, relies on CAS Server to complete user authentication	Third-party business application

The two roles exchange information through the user browser.

CAS SSO Flow

Detailed Steps

1. User accesses application

   User attempts to access application resources provided by CAS Client.

2. Check authentication status

   CAS Client checks whether the current HTTP request contains a Service Ticket (ST):

   • If ST is present, proceed to step 4
   • If not, the user is not yet authenticated; redirect to CAS Server, carrying the Service parameter (the target resource address the user wants to access)

3. User logs in

   User enters authentication information on the CAS Server (BambooCloud IDaaS) login page. After successful login, the CAS Server randomly generates a unique, unforgeable service ticket ST and redirects back to CAS Client.

4. Validate ticket

   After CAS Client obtains the ST, it directly sends a validation request to CAS Server in the background, carrying the Service and ST parameters.

5. Return authentication result

   CAS Server validates the legality of the ST:

   • Validation passed: returns XML containing user info (CAS 2.0/3.0) or plain text (CAS 1.0)
   • Validation failed: returns error information

6. Access resource

   After CAS Client verifies user information, it allows the user to access the requested resource.

CAS Version Differences

Version	Ticket Validation Return Format	User Info
CAS 1.0	Plain text (yes/no)	Only username
CAS 2.0	XML	Returns username and optional attributes
CAS 3.0	XML	Returns richer user attributes, supports attribute release policy

Applicable Scenarios

The CAS protocol is widely used in domestic universities and government systems:

• University informatization: unified authentication for academic systems, library systems, mail systems, etc.
• Government systems: single sign-on among applications of multiple commissions and bureaus
• Traditional Web applications: migration of legacy systems with existing CAS integration

For new projects, it is recommended to prioritize OIDC or SAML protocols for better ecosystem support and richer functionality.