CAS Authentication

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:

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. 

• Java CAS client: 3.6.1
• python-cas: 1.5.0
• Flask-CAS: 1.0.2

The default CAS login page looks like this:

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:

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:
  cas.columbia.edu (production)
  casdev.cc.columbia.edu (test)

CAS server login URL:
  https://cas.columbia.edu/cas/login (production)
  https://casdev.cc.columbia.edu/cas/login (test)

CAS server logout URL:
  https://cas.columbia.edu/cas/logout (production)
  https://casdev.cc.columbia.edu/cas/logout (test)

ticket validation:

  casServerUrlPrefix:
    https://cas.columbia.edu/cas/ (production)
    https://casdev.cc.columbia.edu/cas/ (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.

• In the CAS 3 response and the SAML 1.1 response, it is returned in datetime format as an attribute named "lastPasswordChangeDate. If you use the CAS Java client, see this sample code.
• In the WIND validation response, it is returned in epoch seconds format in the <wind:passwordtime> element. See WIND Ticket Validation Response, note #5.

The Wind authentication service provided at https://wind.columbia.edu 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 https://cas.columbia.edu "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.