CAS is a multiprotocol Web single sign-on (SSO) product composed of a single logical server component that services authentication requests from multiple clients that communicate via one or more supported protocols. The CAS server delegates authentication decisions to any number of supported authentication mechanisms including LDAP/Active Directory, Kerberos, and RDBMS. The hallmark of CAS is ease of integration and extension in support of a wide variety of environments. In addition to supporting a large number of technologies out of the box, the well-documented API extension points have enabled adopters to support novel use cases never imagined by the CAS development team.
Unlike many SSO products, CAS does not use shared cookies to authenticate to services within the SSO domain. The CAS implementation uses a secure SSO session identifier (ticket-granting ticket in CAS protocol parlance), shared exclusively with the CAS server, to generate one-time-use credentials (service tickets in CAS protocol parlance) that are used to access services within the SSO domain. Passing the "master key" session identifier exclusively between the user's browser and CAS server dramatically limits the potential for man-in-the-middle attacks on the session identifier. CAS benefits from increased security in this regard over shared cookie strategies.
The CAS server authenticates users by means of the AuthenticationHandler component for which a number of implementations are provided out of the box to support the following authentication providers:
CAS has a proven track record of supporting custom authentication providers such as proprietary Web services. Adopters leverage the open and well-documented source to develop custom AuthenticationHandler components and wire them into the application using Spring XML configuration. The result is straightforward extension for virtually any authentication need.
The CAS Server supports a number of options for clustering your server instances, each with various positives and trade-offs. You should be able to find one that fits within your environment. There's all an extensive API for providing additional support:
CAS approaches authorization from the perspective that authorization is the responsibility of individual services that authenticate to CAS. This design owes to the history of CAS having been developed in the Higher Education setting, which is typically highly decentralized and ill suited to agreement and enforcement of centralized authorization policy. CAS supports decentralized authorization via an attribute release mechanism where any number of stores may be configured to load and store attributes about principals upon authentication to CAS, and which are released to services when they authenticate to CAS. Attributes are interpreted by services as needed, commonly for authorization and personalization.
CAS is supported by a community of developers and users via a variety of means:
It is important to note that mailing list inquiries typically have response times measured in minutes, with resolutions often occurring same day if not first response. The CAS community spans multiple industries and the globe; with that breadth it is very likely that an active community member has an answer or insight to the problem at hand.
In addition to community support, a number of Jasig partners offer paid support for CAS: