CAS is a Single Sign-On solution for web services. CAS allows different web services to authenticate to one authoritative source of trust, as well as permitting a user to access multiple applications while providing their credentials only once. Web applications can authenticate users without having to handle private information, such as passwords. In addition to authentication, CAS is also able to assert user information for the authenticated user in the form of LDAP attributes and values.

A CAS client is required to interface with the CAS server. There are a number of CAS clients available for a wide variety of programming languages, web servers and middleware. For more information on configuring your CAS client, see the Relevant Articles section below.

Though well adopted in Higher Education, for more universal Web Single Sign-On solution, we also offer SAML 2.0 via Shibboleth. Visit our section on Shibboleth for more information.

The University’s CAS implementation consists of three main production CAS servers in a high availability configuration. The servers have been distributed among multiple data centers to provide redundancy in the event of a disaster. The diagram below shows the server layout, as well as the basic workflow. For more detailed information on how the CAS protocol works, read the article The CAS Protocol for Application Owners.

For authentication, CAS relies on three different backend sources; Kerberos, LDAP, Active Directory. If it fails to authenticate a user with one source, it will move on and try the next. This allows CAS to authenticate different populations, existing in different directory services seamlessly. It also provides redundancy in the event that an authentication service is unavailable.

Relevant Articles

UConn Single Sign-On Integration

The CAS Protocol for Application Owners

Common CAS Client Configuration