In addition to verifying that a user has successfully authenticated with a UNI and password, CAS can provide the following user attributes:
- First name, last name
- Email address
- LDAP affiliations
- Date and time of last password change
- The user, employing a user agent (e.g., a web browser), makes an initial attempt to connect to the application site or entry point, without presenting a service ticket as a request parameter.
- The application detects that the request is not associated with a valid application session and lacks a service ticket parameter and redirects the user agent to the CAS Login URI, adding an additional parameter to the request to indicate where the user should be redirected after successful authentication.
- 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 be configured to include an additional step like Duo multifactor authentication.
- CAS redirects the user agent back to the specified destination URI with a single-use service ticket included as a request parameter.
- The application detects the presence of the service ticket and sends a request to the CAS server to validate the service ticket.
- 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.
- If the CAS response says that the service ticket is valid, the application assumes the user has successfully authenticated.
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 the following authentication protocols:
- CAS 2
- CAS 3
- SAML 1.1 (scroll down to middle of page)
- SAML 2 requests from Google
- WIND, with these limitations (deprecated)
Please note: the CAS 1 protocol is not supported. If all your application needs is UNI authentication with no return of user attributes beyond the username (UNI), configure your CAS client to use CAS 2.
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. There are, however, significant differences in the ticket validation response:
- CAS 2 ticket validation response
- CAS 3 ticket validation response [add]
- SAML 1.1 ticket validation response
- WIND 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: https://[cas-hostname]/cas/login?service=[destination-URI] https://[cas-hostname]/cas/serviceValidate?service=[destination-URI]&ticket=[service-ticket] CAS 3: https://[cas-hostname]/cas/login?service=[destination-URI] https://[cas-hostname]/cas/p3/serviceValidate?service=[destination-URI]&ticket=[service-ticket] SAML 1.1: https://[cas-hostname]/cas/login?TARGET=[destination-URI] https://[cas-hostname]/cas/samlValidate?TARGET=[destination-URI]&SAMLArt=[SAML-SOAP-message-with-service-ticket] WIND: https://[cas-hostname]/cas/login?destination=[destination-URI] https://[cas-hostname]/cas/validate?ticketid=[service-ticket] Logout: https://[cas-hostname]/cas/logout?service=[landing-URI]
Developers who use CAS don't normally write code to implement one of the authentication protocols. Instead, they rely on one of the CAS clients. A CAS client is a layer of software that sits between the application and CAS. It implements one or more of the protocols that CAS supports and presents a simplified interface to the application. The official CAS clients are well-tested, maintained, and documented, and are generally straightforward to use. We strongly recommend using one of the clients rather than writing the code yourself.
These instructions and sample code describe how to use the Java CAS client. Many of the commercial and open source products used in higher education that come with built-in CAS support, including Drupal, WordPress and Sakai, base their support on using one of these CAS clients. This example demonstrates a CAS client configuration that uses the SAML 1.1 protocol. (Although the library versions are out of date, the instructions are still valid.) Depending on your comfort with the client language and the component configuration process (e.g., with tomcat), integration can take from as little as a couple of hours to as much as a few weeks.
Note: It is important to use the current version of a given CAS client to ensure the code includes the latest security fixes. The current version of the CAS Java client is 3.5.1.
The default CAS login page looks like the following:
There are four elements on the CAS login page that can be customized. All of these elements are optional and have default options:
- 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. An application-supplied Help link can be displayed to the left of the "Login" button. The system will default to no help link.
- Custom text. The text for the Help link can also be customized. The text will default to "Help." If there is no link, no text will display.
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:
- 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.
- The application must perform University business.
- 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.
- 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.
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 (business days)
- Initial request - 1 day
- Review of completed request - 3 days
- Review of request with additional user attributes - 7 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
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
SSO allows a user who has established a CAS session to 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 session is valid. This is a feature that a service opts into, meaning that it only works among services that have it enabled. Authentication for services that have not enabled SSO still requires a login with a UNI and password even if a valid SSO session exists for that UNI. 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, not 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.
When a user logs in, CAS sets a cookie that provides 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 (e.g., between Firefox and Chrome).
For CAS services configured to require multifactor authentication (MFA), CAS records which factor(s) have already been used to authenticate in the SSO session and if necessary, forces the user to authenticate with an additional factor to step up to 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.
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.
Affiliations are tags or attributes in the University’s LDAP directory that convey role, group or privilege information. CAS can release selected affiliation values to an application, along with other user attributes. Affiliations can help an application make authorization decisions. However, the information can be quite detailed, and 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.
A request for release of affiliations may also require approval from the data owner(s):
- Alumni Information (David Park, Office of Alumni & Development)
- Barnard College
- Columbia University students (Barry Kane, Columbia University Registrar)
- Columbia University employees (Jim Lindner, Columbia University HR)
- Cunix Groups (CUIT)
- Teachers College
- Union Theological Seminary
Affiliations come in two formats, untranslated ("raw"), in which the affiliations are returned exactly as they appear in LDAP, and translated, in which the affiliations are transformed into a directory-style hierarchy. Requests for release of affiliation data can be for specific affiliation values or for ranges of affiliation values which can be represented as regular expressions.
If you need access to user affiliations, be aware that this information is considered "private directory information," and the University is legally obligated to protect its confidentiality. Permission to access affiliations must be approved by CUIT management. The request for such data should be as specific as possible and include a rationale for its release.
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 Wind protocol support provided by CAS ("legacy Wind over CAS") must migrate their authentication operations to one of the publicly-supported CAS protocols.
The Wind protocol will continue to be supported on the CAS servers at https://cas.columbia.edu/cas for a limited period to help applications make the transition from Wind to CAS. Please contact email@example.com if you need help in this process.
Most Wind clients should see no difference between native Wind and legacy Wind over CAS. Services that were registered for Wind will continue to be 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 the CAS version of Wind. They are supported via the CAS 2 protocol. Click here for an example description of 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 native Wind only requires a Kerberos principal. This means that some test IDs and aliases that can authenticate in native Wind will not be able to authenticate in legacy Wind over CAS as well as other CAS protocols.
- Use of the Wind "service" login parameter is no longer 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 no longer 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 no longer supported, but is replaced by the CAS "renew" parameter. These login parameters allow an application to opt out of single sign-on at runtime by forcing the user to enter login credentials even if the service participates in single sign-on and the user has an active single sign-on session. In native Wind, the syntax was "forcelogin=1." In CAS (and legacy Wind over CAS), it is "renew=true."
- Use of the Wind "passthru" parameter is no longer 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 location 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.
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." See SAML 1.1 response, note #4. If you use the CAS Java client, you can retrieve it with Java code similar to that described for retrieving LDAP affiliations, except that the Attribute name is "lastPasswordChangeDate" and the Attribute type is java.util.Date.
- In the WIND validation response, it is returned in epoch seconds format in the <wind:passwordtime> element. See WIND Ticket Validation Response, note #5.
A CAS service can be configured to require multifactor authentication ("MFA-required"), to have MFA applied optionally ("MFA-optional"), or to not require MFA at all ("MFA-none"), which is the default. If a service is MFA-required, all users must use MFA to log in. If a service is MFA-optional, only those users who have opted in to MFA 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 has opted into MFA for all logins. The CAS single sign-on session records the use of MFA so that a user who has already authenticated with MFA during an active SSO session is not required to re-authenticate with MFA when accessing MFA-protected applications.