3.1. System Integration
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 |
|
|
Perl |
|
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.