CAS Authentication

CAS (Central Authentication Service) is a UNI-based web authentication system for applications that run in a web browser.  

Systems like CAS work by redirecting the user's browser. A request to access a protected resource on the web is intercepted by the application serving the resource or by a component in the web server. Requests that are unrecognized, because they lack either an application session or evidence of a prior authentication, are redirected to the authentication service (CAS) and are returned to the application only after successful authentication. CAS supports multiple authentication protocols, single sign-on (SSO) and multifactor authentication (MFA).

CAS is a Java web application and is open source.  It was originally developed at Yale University in the early 2000's and is now maintained by the Apereo Foundation along with an international community of open-source developers.  Columbia's WIND authentication was an early sibling of CAS, and developers of the two systems collaborated. CAS is widely used in higher education as well as in numerous Fortune 500 companies and non-profits. 

Authentication sequence:

  1. A user with a web browser makes an initial attempt to connect to the application website or entry point, without presenting a service ticket as a request parameter.
  2. The application detects that the request is not associated with a valid application session and lacks a service ticket parameter and redirects the browser to the CAS Login URL, adding an additional parameter to the request to indicate where the browser should be redirected after successful authentication.
  3. The user either authenticates to CAS by submitting a UNI and password which CAS checks against Columbia's Kerberos server, or else presents evidence of a single sign-on session. The authentication may also include an additional step like Duo multifactor authentication.
  4. CAS redirects the browser back to the specified destination URL with a single-use service ticket included as a request parameter.
  5. The application detects the presence of the service ticket and sends a request to the CAS server to validate the service ticket.
  6. The CAS server sends back a ticket validation response indicating whether the service ticket is valid. Depending on the protocol, the response may also contain information about the authentication and the user. Service tickets are single-use; a given ticket can only be successfully validated once.
  7. If the CAS response says that the service ticket is valid, the application can assume the user has successfully authenticated.

See the web flow diagrams for a visual representation of these steps.

Since CAS is a multi-protocol system, details of some of these steps vary depending on the protocol in use. Columbia's CAS server currently supports four authentication protocols.


  • CAS 2
  • CAS 3
  • SAML 1.1 (scroll down to middle of page.)
  • SAML 2 requests from Google (other service providers should use Shibboleth.)

Not supported:

Which protocol should you use?

  • If you need UNI authentication with no additional attributes other than username (UNI), use CAS 2 or CAS 3. CAS 2 is simpler and should be preferred.
  • If you need additional user or authentication attributes, use either CAS 3 or SAML 1.1. CAS 3 is simpler and should be preferred.

Differences among the protocols are not generally evident to the end user. The user connects to an application with a web browser, is redirected to the CAS login page, and on successful authentication is redirected back to the application. However, there are significant differences in the ticket validation response:

The application controls which protocol is used for login and ticket validation by connecting to CAS with the appropriate URL (Steps 2 and 5, above):

Login and service ticket validation:

CAS 2:

CAS 3: 

SAML 1.1:



In addition to verifying that a user has successfully authenticated with a UNI and password, CAS can provide the following information about the user and the authentication:

Attributes available in the ticket validation response:

Developers who use CAS don't normally write code to implement one of the authentication protocols. Instead, they rely on one of the pre-written CAS clients. A CAS client is a component that sits between the application and CAS, handling communication among the application, the end-user and the CAS server by implementing one or more of the protocols that CAS supports. The official CAS clients are well-tested, maintained, and documented, and are generally straightforward to use. We strongly recommend using one of these clients rather than writing one yourself.

Java: These Java instructions and sample code describe how to use and configure the widely-distributed Java CAS client.  

Python: If you are working in Python, consider using python-cas or Flask-CAS. This sample Python webapp uses Flask-CAS.

[ more to come... ] 

Depending on your comfort with the language and the component configuration process (e.g., with tomcat), integration can take as little as 2 hours or as much as two weeks.

It is important to update your CAS client to the latest version to ensure the code includes the latest security fixes. 

The default CAS login page looks like this:

Default CAS login screen

There are three elements on the CAS login page that can be customized. All of these elements are optional and have default values:

  • Custom logo. The logo that is displayed across the top of the inner login box can be replaced with a custom logo in the form of a 440 x 50 pixel image, preferably in GIF format. If you don't supply a logo, the default Columbia CAS logo will be used. It includes a blue crown and the words, "Columbia University in the City of New York," against a white background.
  • Custom links. (true/false) A pre-selected list of Columbia links can be displayed across the top of the page. If you don't supply a value, the system will default to no links.
  • Help link. A custom help link along with a custom label can be displayed to the left of the "Login" button. The help link is defaulted to the Manage My UNI service, and the label is defaulted to "UNI Help".  If you supply a custom help link but no label, the label defaults to simply "Help".

Here are some sample CAS login pages with non-default elements:

CAS login page with custom logo

Submitting a Request

Before an application can use CAS for authentication, the URLs that you want to protect with a login must first be added to the CAS service registry. This is known as "service registration" and is done in response to a Service Registration Request. In CAS documentation, the protected application URLs are called "services" or sometimes "destinations". The registration request also asks for additional information about the application and its use of CAS, and gives application owners an opportunity to customize some elements of the authentication process.

The following are prerequisites for all CAS service registration requests:

  1. The application must be owned or operated by Columbia University, or else run for the benefit of a central administrative unit or department of Columbia University.
  2. The application must perform University business.
  3. The request must be submitted by a full-time Columbia employee and include the name and email address of one technical contact and one administrative contact, both of whom must also be full-time Columbia employees. These contacts are responsible for ensuring that the application conforms to the University's Acceptable Use of IT Resources (Network and Computing) Policy.
  4. The application must be reviewed using the University's Information Security Risk Management Program, and if appropriate, registered with the Relational Security Assessment Manager system (RSAM). See the Information Technology and Risk Management department page for more information.

In addition, CUIT strongly recommends that all registered destinations use SSL encryption. Please consult the advice on use of SSL page for an explanation of the policy and possible exceptions.

To submit a request, create a service request in ServiceNow, copy the Service Registration Request along with your responses into the ServiceNow request, and choose “Identity & Access Management” as the assignment group.

Service Approval

Once the request is complete, it will be reviewed by two members of the Identity and Access Management group, including at least one manager, and checked for secure application practices (e.g., use of SSL) and acceptable use (see the Acceptable Use Policy). If the request is approved, you will be notified that the service has been added to the CAS registry and use of CAS by the application can start.

Expected Turnaround

  • Initial request: 1 business day
  • Review of completed request: 3 business days
  • Review of request with additional user attributes: 7 business days

Changes to a Service Registration

To change a service registration, create a service request in ServiceNow describing the change and choose “Identity & Access Management” as the assignment group. A change to a pre-existing service does not require review and approval unless the change involves an expansion of the rights granted to the service, for example:  

  • Single sign-on (SSO)
  • Release of UNIs
  • Release of additional user attributes

Client Obligations

An application using CAS must keep its service registration up to date. This includes removing destination URLs that are no longer in use and keeping service contacts current. When an application is retired, a request must be made to de-register its CAS service.

Applications that use CAS must follow the University's Acceptable Use Policy. An application in violation of this policy may have its service registration disabled.

CAS server hostname: (production) (test)

CAS server login URL: (production) (test)

CAS server logout URL: (production) (test)

ticket validation:

  casServerUrlPrefix: (production) (test)

  CAS2 protocol:
    validation path:         serviceValidate
    ticketParameterName:     ticket
    serviceParameterName:    service

  CAS3 protocol:
    validation path:         /p3/serviceValidate
    ticketParameterName:     ticket
    serviceParameterName:    service 

  SAML 1.1 protocol:
    validation path:         samlValidate
    artifactParameterName:   SAMLArt
    serviceParameterName:    TARGET
    redirectAfterValidation: true

  WIND protocol (deprecated):
    validation path:         validate
    ticketParameterName:     ticketid
    serviceParameterName:    destination

How does CAS SSO work?  A user who has established a CAS SSO session can authenticate to any SSO-enabled CAS service without having to re-enter a UNI and password (plus additional factors if appropriate), for as long as the SSO session is valid. This is a feature that a service opts into, meaning that it only works among services that have it enabled. Logging into a service that has not enabled SSO does not create an SSO session usable for future logins. Similarly, logging into a service that has not enabled SSO requires a login with a UNI and password even if a valid SSO session exists for that UNI.

SSO session length. A CAS SSO session is valid for a maximum of 60 minutes or 15 minutes of inactivity, whichever occurs first. In this context, activity means a request for a CAS service ticket rather than user entry of keystrokes or mouse clicks. After an SSO session has expired, the next time an application asks CAS to authenticate the user, the user will be required to enter a UNI and password.

SSO cookie and session scope. When a user logs in to an SSO-enabled service, CAS sets a browser cookie containing a reference to the CAS SSO session. The cookie is scoped to the CAS hostname and application path. As a result, the corresponding SSO session is limited to the user agent and CAS. It is not shared across multiple user agents (for example, between Firefox and Chrome.)

Step-up authentication. For CAS services configured to require multifactor authentication (MFA), CAS records which factor(s) have already been used to authenticate and if necessary, forces the user to authenticate with an additional factor to meet the requirement for MFA. This is sometimes called "step-up authentication" or "step-up MFA." A subsequent attempt to access an MFA-protected service with the same active SSO session will not require either username and password or MFA authentication.

Logout. When a user logs out of an application, it is often appropriate to redirect the user agent to the CAS logout URL. This will unset the CAS SSO session cookie and force the user to enter a UNI and password before issuing any more service tickets to the browser.

Requiring MFA.  A CAS service can be configured with 1 of 3 MFA levels:

  • REQUIRED: MFA is required (the default).
  • OPTIONAL: MFA is applied optionally.
  • NONE: MFA is not required. 

If a service is MFA REQUIRED, all users must use MFA to log in. If a service is MFA OPTIONAL, only those users whose MFA level is Optional are required to use MFA to log in. If a service is MFA NONE, no requirement is imposed by CAS for MFA unless the user's MFA level is ALL.  Users can select an MFA level through CUIT's MFA Self Service website, although some schools and departments require all employees to use MFA for all CAS logins (MFA ALL).   Enabling MFA as a requirement does not impose any additional work on the service (you), nor does it complicate your use of CAS.  It does require that end-users must have MFA enabled for their accounts. 

Single sign-on (SSO) and MFA.  The CAS SSO session records the use of MFA.  A user who has already used MFA during an active SSO session is not required to re-authenticate with MFA when accessing MFA-protected applications that have SSO enabled. However, a user who has started an SSO session with only username and password authentication will be required to use Duo MFA when accessing MFA-protected applications that have SSO enabled. 

Affiliations can help an application make authorization decisions, or customize application behavior according to user status.  (For more information on other attributes available to CAS, please see the section What can CAS tell my application?)

Identifying a set of affiliations that will satisfy a specific request can take some effort.  If your service request includes affiliations, please leave time to discuss and verify the selection of affiliations with the Identity and Access Management group.  CUIT typically uses the Grouper group management tool to manage user affiliations.  This tool has built-in "reference groups" that associate with standard demographic categories.  Grouper also has flexibility for delegating management of ad hoc group memberships to application administrators.

Example Scenario 1:  An application should allow access only to CU and Barnard faculty members.  The application administrators may also want to provide access through an additional "allow list."

Example Scenario 2:  An application should allow access only to individuals who are associated with a specific CU department.  Additionally, there are different types of access privileges that should be assigned according to a set of ad hoc group memberships.  

A request for release of affiliations may also require approval from the data owner(s) such as:

  • Office of Alumni and Development
  • Barnard College
  • Columbia University Registrar (CU student info)
  • Columbia University HR (CU employee info)
  • Teachers College
  • Union Theological Seminary

If your application requires access to user affiliations, be aware that this information is in general considered "private directory information," and the University is legally obligated to protect its confidentiality. Permission to access affiliations must be approved by CUIT and the data owners.  The request for such data should be as specific as possible and include a rationale for its release.

PLEASE NOTE:  CAS itself does not handle the authorization of users for your application.  CAS passes affiliations and other attributes to the application, which in turn must be tailored to allow access based upon this user information.  The CAS authentication response itself establishes only that the user has successfully established their identity with user name, password, and any other required factor (such as Duo authentication when required).

The date of last password change is available in the ticket validation response under the CAS 3, SAML 1.1 and Wind protocols, but not under CAS 2.

The Wind authentication service provided at ended on August 22, 2017.

Wind authentication has been unsupported since the beginning of 2016, and application owners still using the Wind protocol support provided by CAS ("legacy Wind over CAS") must migrate their authentication operations to one of these publicly-supported CAS protocols: CAS 2, CAS 3, SAML 1.1.

Legacy Wind over CAS is made available on the CAS servers at "as is" and unsupported. It is available for a limited time to help applications make the transition from Wind to CAS. Please contact [email protected] if you need help in this process. 

Legacy Wind over CAS is very close to the original Wind and most Wind clients are fully compatible with both. Services that were registered for Wind have been registered for legacy Wind over CAS. Both ticket validation response formats, text and xml, are supported. However, there are some limitations and differences:

  • Proxy tickets are not supported in legacy Wind over CAS. They are supported via the CAS 2 and CAS 3 protocols. See these instructions for configuring CAS proxy tickets.
  • As part of the authentication process for all protocols, CAS verifies that a UNI has a corresponding record in LDAP, as well as a Kerberos principal. The original Wind only required a Kerberos principal. This means that some test IDs and aliases that could authenticate in the original Wind are not be able to authenticate in legacy Wind over CAS as well as the other CAS protocols.
  • Use of the Wind "service" login parameter is not supported. The service parameter could be used to coerce Wind to use a specific service configuration to handle an authentication request, rather than derive the service from the destination URL. This usage had been deprecated and is now no longer supported. Please Note: The Wind "service" parameter is different from the CAS "service" parameter, which is equivalent to the Wind "destination" parameter.
  • Use of the Wind "sendxml" parameter is not supported. The sendxml parameter could be used at runtime to change the response format of a ticket validation request from text to xml, if the response format at service registration time was text. (The reverse was not true, the parameter could not be used to change the format from xml to text.) In legacy Wind over CAS, the response format is controlled by the service registration value.
  • Use of the Wind "forcelogin" parameter is not supported, but is replaced by the CAS "renew" parameter. These login parameters allow an application to opt out of single sign-on at runtime and require the user to enter login credentials even if the service has single sign-on enabled and the user has an active single sign-on session. In the original Wind, the syntax was "forcelogin=1." In CAS (and legacy Wind over CAS), it is "renew=true."
  • Use of the Wind "passthru" parameter is not supported, but is replaced by the CAS "service" parameter. When added to a Wind logout request, the "passthru" parameter instructed Wind to redirect the browser to the passthru URL following logout. In CAS and legacy Wind over CAS, this function is performed by adding a "service" parameter to the logout request. The value of this parameter must be present in the service registry.