Merged into new managed-in-source-control DocBook documentation

This content, as of version 7 of this page, has been merged into the new managed-in-source-control DocBook documentation of the cas-server product.

If you'd like to improve this documentation, please do! But your improvement needs to go where this documentation now lives and continues to evolve. Please create a JIRA and propose a patch, etc.

3.1. System Integration

Enterprise deployment planning begins with careful consideration of existing software and systems to be integrated with CAS including applications, identity management and authentication services, and other supporting enterprise services.

3.1.1. CAS Client Integration

The following CAS clients are used to integrate 90% of commercial and open source applications:

Java CAS Client
.NET CAS Client
mod_auth_cas module for Apache
phpCAS

Additionally, custom applications developed in common languages/platforms are easily supported in most cases. In almost all cases Web applications are easily integrated with CAS. Difficulty commonly arises, however, with applications built on legacy frameworks such as database procedural languages (e.g. PL/SQL) or mainframe applications. These kinds of applications frequently require creative solutions for CAS integration, but there are many such examples in community-contributed integration solutions that showcase the flexibility of CAS.

The following matrix summarizes popular applications and the required libraries for CAS integration.

Application/Framework	CAS Client	Officially Supported
Outlook Web Access	.NET CAS Client + Clearpass Extension
Apache	mod_auth_cas
ASP.NET	.NET CAS Client
IIS7 Integration	.NET CAS Client
Java servlets	Java CAS Client
Spring Security	Spring Security + Java CAS Client
PHP Applications	phpCAS
Ruby on Rails	rubycas-client
Perl	PerlCAS

3.1.2. Authentication

CAS must be integrated with one or more enterprise authentication systems such as LDAP/Active Directory. While it is most common to integrate CAS with a single enterprise authentication system, it is possible to integrate with multiple systems given the following important requirement.

Using Multiple Authentication Sources

The namespaces of each authentication source must be guaranteed to be unique in order to prevent ambiguity about the identity of the authenticating user. In particular neither a credential such as a username nor the name of the resolved principal may exist in more than one authentication source.

The following authentication mechanisms are available in CAS.

Active Directory
Generic
JAAS
RDBMS/Database
LDAP
Legacy
RADIUS
SPNEGO
Trusted (e.g. REMOTE_USER)
X.509 Certificates

3.1.3. Attribute Release/Authorization

In addition to authenticating the user, CAS is capable of querying for additional attributes about a user following authentication in order to store and release some or all of this information to requesting services for the purposes such as authorization and personalization. Attribute data is commonly sourced from the same store as authentication data, but the design of attribute retrieval allows configuring multiple disparate attribute sources.

3.1.4. Supporting Services

Many enterprises have services that may be leveraged by CAS. For example, the availability of enterprise database hosting might suggest the use of JpaTicketRegistry for the server ticket store. Likewise clustering hardware or software might be used by CAS for improved availability and/or capacity.