Introduction

Features

SSO Implementation

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.

Authentication Providers

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:

• LDAP/Active Directory
• RDBMS
• Kerberos
• SPNEGO
• X.509/Client SSL
• JAAS
• RADIUS
• Flat file

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.

Clustering

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:

• JPA
• JBoss Infinispan
• Memcached
• Ehcache

Authorization

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.

Product Comparison

Support

CAS is supported by a community of developers and users via a variety of means:

• Formal product documentation
• Real-time user support via the cas-user@lists.jasig.org mailing list
• Jasig conferences

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:

• Unicon Cooperative Support for CAS