CAS 101: Introduction to CAS (Central Authentication Service)

CAS Introduction

The Central Authentication Service (CAS) is a single-sign-on / single-sign-off protocol for the web. It permits a user to access multiple applications while providing their credentials (such as userid and password) only once to a central CAS Server application.

The CAS protocol is a simple and powerful ticket-based protocol.

Key Conception

• The CAS server is the Central Authentication Service server. It responsible for authenticating users and granting accesses to applications.

• CAS Client is the software component that is integrated with a web application and interacts with the CAS server via CAS protocol. It response retrieve the identity of the granted users from the CAS server.

• service ticket: A service ticket is an opaque string that is used by the client as a credential to obtain access to a service. The service ticket is obtained from CAS upon a client’s presentation of credentials and a service identifier to /login

CAS URIs

CAS is an HTTP-based protocol that requires each of its components to be accessible through specific URIs.

/login Simple login example:

https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice

The service query parameter here is the URL of the application. This URL value MUST be URL-encoded. In this example, service is http://Fwww.example.org/service Once CAS server authenticated user, it will redirect to this URL with a serviceTicket query parameter.

/logout destroys a client’s single sign-on CAS session. The ticket-granting cookie is destroyed, and subsequent requests to /login will not obtain service tickets until the user again presents primary credentials (and thereby establishes a new single sign-on session).

/validate [CAS 1.0] checks the validity of a service ticket. /validate is part of the CAS 1.0 protocol and thus does not handle proxy authentication. CAS MUST respond with a ticket validation failure response when a proxy ticket is passed to /validate.

/serviceValidate [CAS 2.0] checks the validity of a service ticket and returns an XML-fragment response. /serviceValidate MUST also generate and issue proxy-granting tickets when requested. /serviceValidate MUST NOT return a successful authentication if it receives a proxy ticket. It is RECOMMENDED that if /serviceValidate receives a proxy ticket, the error message in the XML response SHOULD explain that validation failed because a proxy ticket was passed to /serviceValidate.

/proxyValidate [CAS 2.0] MUST perform the same validation tasks as /serviceValidate and additionally validate proxy tickets. /proxyValidate MUST be capable of validating both service tickets and proxy tickets.

/proxy [CAS 2.0] provides proxy tickets to services that have acquired proxy-granting tickets and will be proxying authentication to back-end services.

/p3/serviceValidate [CAS 3.0] MUST perform the same validation tasks as /serviceValidate and additionally return user attributes in the CAS response.

/p3/proxyValidate [CAS 3.0] MUST perform the same validation tasks as /p3/serviceValidate and additionally validate proxy tickets.

Example Authentication Flow

The following diagram show an example authentication flow use CAS server.

Step 1: User initial authentication request

Step 2: Browser send login request to CAS client

Step 3-4: CAS client redirect login request to CAS server

Below are examples response in step 3 and request in step 4:

302 Found
Location: https://cas-server/cas/login?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F

GET https://cas-server/cas/login?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F

Step 5-6: CAS server show login form to user

Step 7-8: User submit login form

User send login credentials like username, password to CAS server directly. The request include service query parameter to indicate CAS server which service is doing authentication.

POST https://cas-server/cas/login?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F

Step 9: CAS server redirect user to CAS client with service ticket

service ticket in query parameter ticket. CAS Client need validate ticket in following step.

Below is an example response

302 Found
Location: https://cas-app/accounts/login?next=%2F&ticket=ST-1579821158

Step 10: Validate service ticket through /serviceValidate

CAS Client need validate service ticket (ST) through CAS server /serviceValidate API.

The request is a GET request with service and ticket query parameter.

Below is an example request:

GET https://cas-server/cas/serviceValidate?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F&ticket=ST-1579821158

Step 11: Response to /serviceValidate

CAS response /serviceValidate to CAS client, the response is in XML format. If validate success, it will include user attributes (like username) in response.

Below is an example of /serviceValidate ticket validation successful XML response:

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
 <cas:authenticationSuccess>
  <cas:user>foo</cas:user>
  <cas:proxyGrantingTicket>PGTIOU-234749-5d3e...</cas:proxyGrantingTicket>
 </cas:authenticationSuccess>
</cas:serviceResponse>

Below is an example of /serviceValidate ticket validation failure XML response:

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">
 <cas:authenticationFailure code="INVALID_TICKET">
    Ticket  PGTIOU-234749-5d3e12d2df87dc not recognized
  </cas:authenticationFailure>
</cas:serviceResponse>

Step 12: CAS client redirect after validate ticket successfully

CAS client redirect according next query parameter in service.

CAS client also set cookie in browser to store session info.

Step 13: Browser follow redirect request

Browser also add cookie in request header to indicate user is logged in.

Step 14-15: CAS client response content to user

In step 14, CAS client need validate session cookie.

Reference

• CAS Protocol Specification

OmniLock - Block / Hide App on iOS

Block distractive apps from appearing on the Home Screen and App Library, enhance your focus and reduce screen time.

DNS Firewall for iOS and Mac OS

Encrypted your DNS to protect your privacy and firewall to block phishing, malicious domains, block ads in all browsers and apps

Ad

• Next →