Architecture 架构
The CAS server and clients comprise the two physical components of the CAS system architecture that communicate by means of various protocols.
CAS Server
The CAS server is Java servlet built on the Spring Framework whose primary responsibility is to authenticate users and grant access to CAS-enabled services, commonly called CAS clients, by issuing and validating tickets. An SSO session is created when the server issues a ticket-granting ticket (TGT) to the user upon successful login. A service ticket (ST) is issued to a service at the user’s request via browser redirects using the TGT as a token. The ST is subsequently validated at the CAS server via back-channel communication. These interactions are described in great detail in the CAS Protocol document.
CAS Clients
The term “CAS client” has two distinct meanings in its common use. A CAS client is any CAS-enabled application that can communicate with the server via a supported protocol. A CAS client is also a software package that can be integrated with various software platforms and applications in order to communicate with the CAS server via some authentication protocol (e.g. CAS, SAML, OAuth). CAS clients supporting a number of software platforms and products have been developed.
Platforms:
Apache httpd Server (mod_auth_cas module)
Java (Java CAS Client)
.NET (.NET CAS Client)
PHP (phpCAS)
Perl (PerlCAS)
Python (pycas)
Ruby (rubycas-client)
Applications:
Outlook Web Application (ClearPass + .NET CAS Client)
Atlassian Confluence
Atlassian JIRA
Drupal
Liferay
uPortal
When the term “CAS client” appears in this manual without further qualification, it refers to the integration components such as the Jasig Java CAS Client rather than to the application relying upon (a client of) the CAS server.
Protocols
Clients communicate with the server by any of several supported protocols. All the supported protocols are conceptually similar, yet some have features or characteristics that make them desirable for particular applications or use cases. For example, the CAS protocol supports delegated (proxy) authentication, and the SAML protocol supports attribute release and single sign-out.
Supported protocols:
CAS (versions 1, 2, and 3)
SAML 1.1
OpenID
OAuth (1.0, 2.0)
Software Components
It is helpful to describe the CAS server in terms of three layered subsystems:
Web (Spring MVC/Spring Webflow)
Ticketing
Authentication
Almost all deployment considerations and component configuration involve those three subsystems. The Web tier is the endpoint for communication with all external systems including CAS clients. The Web tier delegates to the ticketing subsystem to generate tickets for CAS client access. The SSO session begins with the issuance of a ticket-granting ticket on successful authentication, thus the ticketing subsystem frequently delegates to the authentication subsystem.
The authentication system is typically only processing requests at the start of the SSO session, though there are other cases when it can be invoked (e.g. forced authentication).
Installation Requirements
Requirements at a glance:
Java >=1.7
Servlet container supporting servlet specification >= 3.0
Apache Maven >=3.3
Familiarity with the Spring Framework
Internet connectivity
Depending on choice of configuration components, there may be additional requirements such as LDAP directory, database, and caching infrastructure. In most cases, however, requirements should be self evident to deployers who choose components with clear hardware and software dependencies. In any case where additional requirements are not obvious, the discussion of component configuration should mention system, software, hardware, and other requirements.
Servlet Containers
There is no officially supported servlet container for CAS, but Apache Tomcat is the most commonly used. Support for a particular servlet container depends on the expertise of community members, but the following are known to work well and should receive first-class support on the Community Discussion
Mailing List:
- JBoss
- Jetty
- GlassFish
- WebSphere
Apache Maven
CAS uses Maven for building and creating a deployable package for instllation into a Java servlet container. Maven is also strongly recommended for configuration management required for the CAS installation process. CAS is fundamentally a complex software product that becomes embedded and tighly integrated into the software environment of an institution. For this reason it tends to require customization well beyond turnkey solutions, and the integration requirements tend to change over time. A source-based installation process like Maven WAR overlay provides a straightforward and flexible solution to complex and dynamic requirements. While it admittedly requires a high up-front cost in learning, it reaps numerous benefits in the long run
Spring Framework
CAS uses the many aspects of the Spring Framework; most notably, Spring MVC and Spring Webflow. Spring provides a complete and extensible framework for the core CAS codebase as well as for deployers; it’s straightforward to customize or extend CAS behavior by hooking CAS and Spring API extension points. General knowledge of Spring is beneficial to understanding the interplay among some framework compoents, but it’s not strictly required. The XML-based configuration used to configure CAS and Spring components, however, is a core concern for installation, customization, and extension. Competence with XML generally and the Spring IOC Container in particular are prerequisites to CAS installation.
Internet Connectivity
Internet connectivity is generally required for the build phase of any Maven-based project, including the recommended Maven WAR overlays used to install CAS. Maven resolves dependencies by searching online repositories containing artifacts (jar files in most cases) that are downloaded and installed locally. While it is possible to override this behavior by alterning Maven configuration settings, it is considered advanced usage and not supported.
A common solution to overcoming lack of Internet connectivity on a CAS server is to build CAS on a dedicated build host with internet connectivity. The cas.war file produced by the build is subsequently copied to the CAS server for deployment.
Security Guide
CAS is security software that provides secure Web-based single sign-on to Web-based applications. Single sign-on provides a win/win in terms of security and convenience: it reduces password exposure to a single, trusted credential broker while transparently providing access to multiple services without repetitious logins. The use of CAS generally improves the security environment, but there are several CAS configuration, policy, and deployment concerns that should be considered to achieve suitable security.
System Security Considerations
Secure Transport (https)
All communication with the CAS server MUST occur over a secure channel (i.e. TLSv1). There are two primary justifications for this requirement:
The authentication process requires transmission of security credentials.
The CAS ticket-granting ticket is a bearer token.
Since the disclosure of either data would allow impersonation attacks, it’s vitally important to secure the communication channel between CAS clients and the CAS server.
Practically, it means that all CAS urls must use HTTPS, but it also means that all connections from the CAS server to the application must be done using HTTPS:
when the generated service ticket is sent back to the application on the “service” url
when a proxy callback url is called.
Connections to Dependent Systems
CAS commonly requires connections to other systems such as LDAP directories, databases, and caching services. We generally recommend to use secure transport (SSL/TLS, IPSec) to those systems where possible, but there may be compensating controls that make secure transport uncessary. Private networks and corporate networks with strict acces controls are common exceptions, but secure transport is recommended nonetheless. Client certification validation can be another good solution for LDAP to bring sufficient security.
As stated previously, connections to other systems must be secured. But if the CAS server is deployed on several nodes, the same applies to the CAS server itself. If a cache-based ticket registry runs without any security issue on a single CAS server, synchronization can become a security problem when using multiple nodes if the network is not protected.
Any disk storage is also vulnerable if not properly secured. EhCache overflow to disk may be turned off to increase protection whereas advanced encryption data mechanism should be used for the database disk storage.
Deployment-Driven Security Features
CAS supports a number of features that can be leveraged to implement various security policies. The following features are provided through CAS configuration and CAS client integration. Note that many features are available out of the box, while others require explicit setup.
Forced Authentication
Many CAS clients and supported protocols support the concept of forced authentication whereby a user must reauthenticate to access a particular service. The CAS protocols support forced authentication via the renew parameter. Forced authentication provides additional assurance in the identity of the principal of an SSO session since the user must verify his or her credentials prior to access. Forced authentication is suitable for services where higher security is desired or mandated. Typically forced authentication is configured on a per-service basis, but the service management facility provides some support for implementing forced authentication as a matter of centralized security policy. Forced authentication may be combined with multi-factor authentication features to implement arbitrary service-specific access control policy.
Passive Authentication
Some CAS protocols support passive authentication where access to a CAS-protected service is granted anonymously when requested. The CASv2 and CASv3 protocols support this capability via the gateway feature. Passive authentication complements forced authentication; where forced authentication requires authentication to access a service, passive authentication permits service access, albeit anonymously, without authentication.
Proxy Authentication
Proxy authentication, or delegated authentication, provides a powerful, important, and potentially security-improving feature of CAS. Proxy authentication is supported by the CASv2 and CASv3 protocols and is mediated by proxy tickets that are requested by a service on behalf of a user; thus the service proxies authentication for the user. Proxy authentication is commonly used in cases where a service cannot interact directly with the user and as an alternative to replaying end-user credentials to a service.
However, proxy tickets carry risk in that services accepting proxy tickets are responsible for validating the proxy chain (the list of services through which the end-user’s authentication have been delegated to arrive at the ticket validating service). Services can opt out of accepting proxy tickets entirely (and avoid responsibility for validating proxy chains) by simply validating tickets against the /serviceValidate validation endpoint, but experience has shown it’s easy to be confused about this and configure to unintentionally use the /proxyValidate endpoint yet not scrutinize any proxy chains that appear in the ticket validation response. Thus proxy authentication requires careful configuration for proper security controls; it is recommended to disable proxy authentication components at the CAS server if proxy authentication is not needed.
Historically any service could obtain a proxy-granting ticket and from it a proxy ticket to access any other service. In other words, the security model is decentralized rather than centralized. The service management facility affords some centralized control of proxy authentication by exposing a proxy authentication flag that can enabled or disabled on a per-service basis. By default registered services are not granted proxy authentication capability.
Multi-factor Authentication
CAS provides support for multi-factor authentication in one of two modes: global and per-service. The global case where multiple credentials are invariably required on the login form is straightforward: the user interface is modified to accept multiple credentials and authentication components are configured to require successful authentication of all provided credentials.
The per-service case is both more interesting and more complicated:
Levels of identity assurance (LOA) for credentials and groups of credentials must be established.
Security policy versus credential LOA must be established per service.
Service access policy must be configured via the service management facility.
The first two tasks are vital but outside the scope of this document. Application of service access policy via the service management facility is implemented by declaring the authentication handlers that must successfully authenticate credentials in order to permit access; for example, an LDAP authentication handler and an RSA SecureID authentication handler.
Since multi-factor authentication requires development of institutional security policy, advanced component configuration (and possibly custom component development), and UI design, it should be regarded more as a framework than a feature. See the multi-factor configuration section for detailed discussion of configuration concerns and implementation recommendations.
Credential Caching and Replay
The ClearPass extension provides a mechanism to capture primary authentication credentials, cache them (encrypted), and replay on demand as needed to access legacy services. While proxy authentication is recommended in lieu of password replay, it may be required to integrate legacy services with CAS. See the ClearPass documentation for detailed information.
Service Management
The service management facility provides a number of service-specific configuration controls that affect security policy and provide some support for centralized security policy. (Note that CAS has historically supported the decentralized security policy model.) Some highlights of service management controls:
Authorized services
Forced authentication
Attribute release
Proxy authentication control
Theme control
Multi-factor service access policy
The service management facility is comprised of a service registry containing one or more registered services, each of which specifies the management controls above. The service registry can be controlled via static configuration files, a Web user interface, or both. See the Service Management section for more information.
Authorized Services
As a security best practice, it is strongly recommended to limit the service management facility to only include the list of known applications that are authorized to use CAS. Leaving the management interface open for all applications may create an opportunity for security attacks.
SSO Cookie Encryption
A ticket-granting cookie is an HTTP cookie set by CAS upon the establishment of a single sign-on session. The cookie value is by default encrypted and signed via settings defined in cas.properties. While sample data is provided for initial deployments, these keys MUST be regenerated per your specific environment. Please see this guide for more info.
Ticket Expiration Policies
Ticket expiration policies are a primary mechanism for implementing security policy. Ticket expiration policy allows control of some important aspects of CAS SSO session behavior:
SSO session duration (sliding expiration, absolute)
Ticket reuse
See the Configuring Ticketing Components section for a detailed discussion of the various expiration policies and configuration instructions.
Single Sign-Out
Single sign-out, or single log-out (SLO), is a feature by which CAS services are notified of the termination of a CAS SSO session with the expectation that services terminate access for the SSO session owner. While single sign-out can improve security, it is fundamentally a best-effort facility and may not actually terminate access to all services consumed during an SSO session. The following compensating controls may be used to improve risks associated with single sign-out shortcomings:
Require forced authentication for sensitive services
Reduce application session timeouts
Reduce SSO session duration
SLO can happen in two ways: from the CAS server (back-channel logout) and/or from the browser (front-channel logout). For back-channel logout, the SLO process relies on the SimpleHttpClient class which has a threads pool: its size must be defined to properly treat all the logout requests. Additional not-already-processed logout requests are temporarily stored in a queue before being sent: its size is defined to 20% of the global capacity of the threads pool and can be adjusted. Both sizes are critical settings of the CAS system and their values should never exceed the real capacity of the CAS server.
Login Throttling
CAS supports a policy-driven feature to limit successive failed authentication attempts to help prevent brute force and denial of service attacks. The feature is beneficial in environments where back-end authentication stores lack equivalent features. In cases where this support is available in underlying systems, we encourage using it instead of CAS features; the justification is that enabling support in underlying systems provides the feature in all dependent systems including CAS. See the login throttling configuration section for further information.
Credential Encryption
An open source product called Java Simplified Encryption allows you to replace clear text passwords in files with encrypted strings that are decrypted at run time. Jasypt can be integrated into the Spring configuration framework so that property values are decrypted as the configuration file is loaded. Jasypt’s approach replaces the the property management technique with one that recognizes encrypted strings and decrypts them. This method uses password-based encryption, which means that the system still needs a secret password in order to decrypt our credentials. We don’t want to simply move the secret from one file to another, and Jasypt avoids that by passing the key as an environment variable or even directly to the application through a web interface each time it is deployed.
This ability is beneficial since it removes the need to embed plain-text credentials in configuration files, and allows the adopter to securely keep track of all encrypted settings in source control systems, safely sharing the build configuration with others. Sensitive pieces of data are only restricted to the deployment environment.
CAS Security Filter
The CAS project provides a number of a blunt generic security filters suitable for patching-in-place Java CAS server and Java CAS client deployments vulnerable to certain request parameter based bad-CAS-protocol-input attacks. The filters are configured to sanitize authentication request parameters and reject the request if it is not compliant with the CAS protocol in the event that for instance, a parameter is repeated multiple times, includes multiple values, contains unacceptable values, etc.
It is STRONGLY recommended that all CAS deployments be evaluated and include this configuration if necessary to prevent protocol attacks in situations where the CAS container and environment are unable to block malicious and badly-configured requests.
Spring Webflow Sessions
The CAS project uses Spring Webflow to manage and orchestrate the authentication process. The conversational state of the webflow used by CAS is managed by the client which is then passed and tracked throughout various states of the authentication process. This state must be secured and encrypted to prevent session hijacking. While CAS provides default encryptions settings out of the box, it is STRONGLY recommended that all CAS deployments be evaluated prior to production rollouts and regenerate this configuration to prevent attacks.
User-Driven Security Features
The following features may be employed to afford some user control of the SSO experience.
Long Term Authentication
The long term authentication feature, commonly referred to as “Remember Me”, is selected (usually via checkbox) on the CAS login form to avoid reauthentication for an extended period of time. Long term authentication allows users to elect additional convenience at the expense of reduced security. The extent of reduced security is a function of the characteristics of the device used to establish a CAS SSO session. A long-term SSO session established from a device owned or operated by a single user is marginally less secure than a standard CAS SSO session. The only real concern would be the increased lifetime and resulting increased exposure of the CAS ticket-granting ticket. Establishing a long-term CAS SSO session from a shared device, on the other hand, may dramatically reduce security. The likelihood of artifacts from previous SSO sessions affecting subsequent SSO sessions established by other users, even in the face of single sign-out, may increase the likelihood of impersonation. While there are no feasible mitigations for improving security of long-term SSO sessions on a shared device, educating users on the inherent risks may improve overall security.
It is important to note that forced authentication supercedes long term authentication, thus if a service were configured for forced authentication, authentication would be required for service access even in the context of a long-term session.
Long term authentication support must be explicitly enabled through configuration and UI customization during the installation process. Thus deployers choose to offer long-term authentication support, and when available users may elect to use it via selection on the CAS login form.
Warn
CAS supports optional notification of service access during an established SSO session. By default CAS transparently requests tickets needed for service access and presents them to the target service for validation, whereby upon successful validation access to the service is permitted. In most cases this happens nearly instantly and the user is not aware of the CAS authentication process required to access CAS-enabled services. There may be some security benefit to awareness of this process, and CAS supports a warn flag that may be selected by the user on the CAS login screen to provide an interstitial notification page that is displayed prior to accessing a service. By default the notification page offers the user an option to proceed with CAS authentication or abort by navigating away from the target service.
High Availability Guide (HA/Clustering)
A highly available CAS deployment is one that offers resilience in response to various failure modes such that CAS continues to offer SSO services despite failures. We offer a recommended architecture that provides a starting point for planning and executing a CAS deployment that meets institutional performance and availability requirements. It also provides a framework for understanding CAS software component requirements imposed by HA considerations.
A high availability (HA) configuration of CAS is achieved by ensuring there is adequate redundancy so that the service is robust in the face of component failures and that routine maintenance can be done without service downtime. This can be achieved with multi-node and to a lesser degree with single-node CAS with advanced virtual machine capabilities. This document will focus on the CAS Server components required to achieve HA. A more quantitative analysis of HA configuration depends on supporting infrastructure and services and is beyond the scope of this document.
The CAS Server software has had a great track record of being extremely reliable. However, the CAS Server is only a small part of software and hardware that authentication has to traverse to work smoothly. Clustering has typically been used by deployers not only for load handling but also for fail-over. Even if a failure does not occur, it is sometimes desirable to restart a server. For example, if a serious security fix at the operating system level was installed, the server should be restarted immediately. In a cluster of CAS servers, this could be easily accomplished with a rolling restart even during the busiest time.
Operating a single server traditionally would delay such a restart until a less busy time, while running with a known vulnerability. However, more recently with the growing acceptance of virtual machine technology and its inherent redundancy and fault tolerance, single node CAS has been able to achieve similar qualities.
Recommended Architecture
The following diagram highlights the vital aspects of a highly available CAS deployment.
It’s worth pointing out some important characteristics of this architecture:
- Dependent systems can tolerate up to N-1 node failures. (Where N is the total number of nodes.)
- CAS itself can tolerate up to N-1 node failures.
- Loss of a cache node DOES NOT cause loss of SSO state data (i.e. tickets) in replicating caches.
- Loss of a cache node MAY cause loss of SSO state data in non-replicating caches (e.g. memcached).
- Loss of SSO state data is always graceful: users simply reauthenticate.
Before proceeding into a detailed discussion of various aspects of the recommended architecture, we offer a guiding principle for planning a highly available deployment:
Experience has shown that simplicity is a vital system characteristic of successful and robust HA deployments. Strive for simplicity and you will be well served.
Deployment Scenarios
Single-node CAS, HA VM Infrastructure
High availability can be achieved by implementing a single-node CAS running in a sophisticated virtualized environment. This approach to high availability is attractive in the sense that it simplifies the CAS server configuration but requires hardware virtualization technology that may not be present and available.
Physical Architecture
In a single-node VM architecture, the CAS server, along with the necessary prerequisites and software dependencies is deployed in a single host VM. Under this deployment scenario the default in-memory Ticket Registry is sufficient and no Servlet Session replication is required. This simplifies the deployment configuration and is the recommended approach if the VM infrastructure is sufficient to meet HA and scalability needs.
Robustness
Hardware component failure/recovery is a feature of the virtualized environment such that the loss of a CPU, memory or power does not cause a failure of the CAS server.
Zero downtime maintenance approach
True zero downtime maintenance (i.e. no observable impact to end users) is not achievable with this configuration. However, staging of maintenance and upgrades can be done without downtime by leveraging the cloning ability of most VM infrastructures. Once the new CAS Server node is ready, a brief cutover can be implemented which will effectively end all current SSO sessions. This could be done by scheduling restart of Tomcat during low traffic times, after the new cas.war has been deployed.
Scalability
CAS itself has modest computing requirements such that any modern enterprise class server hardware is going to be sufficient to handle 10,000s of users in typical deployment scenarios. In a recent client engagement load testing a single node deployment yielded good results with CAS handling 200 concurrent users at 61 requests per second which roughly translates into 108,000 authentication transactions per hour. These number are of course representative and any benchmark will be highly dependent on local infrastructure. VM environments should be able to scale the available CPU and memory to meet a wide range of needs.
Multiple CAS Server Nodes
A highly available CAS deployment is composed of two or more nodes behind a hardware load balancer in either active/passive or active/active mode. In general the former offers simplicity with adequate failover; the latter, improved resource usage and reduced service interruptions at the cost of additional complexity. Active-passive configuration can be done with manual or automatic failover in the case where the primary CAS node fails. Active-active configuration is possible with a clustered ticket registry state such that any available CAS node can service any request for the CAS server. A number of options are available for implementing an active-active configuration with shared ticket state.
HA can be achieved by implementing a multi-node CAS deployment running on multiple VMs or physical hosts. This approach is attractive since it allows true zero down-time maintenance of the service at the cost of a marginal increase in deployment complexity.
Multi-node CAS generally involves the following:
Installing multiple instances of the CAS server (so that one or more of the servers can be destroyed without the CAS service becoming unavailable)
Configuring the multiple instances of the CAS server to share ticket state (so that regardless of which CAS server a user or service interacts with, the response from each CAS server is the same.)
Configuring a solution for directing traffic among the clustered CAS servers, for detecting component failure and removing failed components from service
Optionally, configuring a solution for sharing session state and session failover across the CAS instances (this isn’t typically appropriate, since end-user CAS sessions tend to be short lived and the experience is more request-response style than it is session oriented) - favor short-lived sticky (aka persistent sessions) load-balancing instead (could be a problem with large NAT deployments)
Having appropriate contingency plans such that the desired margin of headroom against failure is restored when it is exercised. (For example, having three CAS server instances, clustered, serving a load that can be serviced with just two instances.)
Physical Architecture
The physical architecture may be realized through VMs or physical hardware. It is important to note that in a shared ticket state model (Active/Active mode), CAS server nodes need to be able to communicate tickets state across all nodes and as such, firewall restrictions between such nodes needs to be relaxed enough to allow for ticket state replication.
The service endpoint is a virtual IP address configured at the load balancer. Thus all requests are handled by the load balancer and then routed to available CAS nodes.
Robustness
In the event of a CAS node failure, the work load and authentication requests can properly be rerouted to another CAS node. It is possible that through the failover scenario, some state may be lost depending on where the user is in the login flow and as such, once the rerouting of the request has landed from the failed node to the clone, users may need be presented with the CAS login screen again. This failure mode can be eliminated with Servlet session state replication.
Zero downtime maintenance approach
Maintenance work, such that it would include upgrades and application of patches to the software may be carried out via two general approaches:
In active-passive models, work may be carried out offline on the passive CAS node. The load balancer is then tweaked to switch over the prepared node once ready thereby switching the active-passive nodes around. This results in all CAS SSO sessions being reset and possibly some Ticket validation failures if done during times with high utilization. See below for more details on this approach.
In active-active models, one node can be taken offline while at least one other CAS server node remains alive to respond to requests. Once the upgrade procedure is done, the server can return to the pool while obtaining the ticket state from other active nodes. Certain distributed ticket registry models have the ability to bootstrap themselves by receiving ticket data from other nodes without any manual configuration or adjustment. See below for more details on this approach.
Scalability
Scalability is simply achieved by adding new CAS nodes to the cluster.
Active/Passive Mode
In an active/passive load balanced configuration, 1 of N nodes serves all requests at any given time. This simplifies ticket storage requirements since it is not necessary to share ticket state among several application nodes.
In particular, the DefaultTicketRegistry component that stores tickets in memory is suitable for active/failover setups with the understanding that a node failure would result in ticket loss. It’s worth repeating that ticket loss results in graceful application failure where users simply reauthenticate to CAS to create new SSO sessions; CAS client sessions created under prevous SSO sessions would suffer no iterruption or loss of data.
Active/Active Mode
A load balancer in active/active mode serves requests to all N nodes similutaneously. The load balancer chooses a node to serve a request based on a configured algorithm; typically least active or round robin. In this system architecture, it is vitally important to use a ticket store where a ticket can be located regardless of which CAS node requests it.
It’s instructive to discuss the origin of this requirement. There are two interactions for tickets that occur from fundamentally different network sources:
User’s Web browser contacts CAS to generate a ticket.
Target service contacts CAS with a ticket to validate it.
Since both requests flow through the load balancer from different source addresses, it is not possible to guarantee that both requests are serviced by the same CAS node. Thus the requirement that a ticket be locatable regardless of the CAS node that requests it. It should be clear why in-memory storage is not suitable for active/active deployments.
The active-active architecture allows for a zero down-time transitions between CAS server versions at the time of upgrades. One CAS node instance can be taken offline, undergo maintenance, and then be put back into the production. The same strategy is then repeated for all other CAS nodes.
There is a further consideration for active/active deployments: session affinity. Session affinity is a feature of most load balancer equipment where the device performs state management for incoming requests and routes a client to the same node for subsequent requests for a period of time. This feature is recommended and required to avoid servlet container session replication, which is generally more complex and less reliable. The core of this requirement is that servlet container session storage is used to maintain state for the CAS login and logout Webflows. While it is possible to achieve truly stateless active/active deployments by plugging in client-based state management components, such configurations at present have not been proven and are not recommended without careful planning and testing.
Avoid Round Robin DNS
We strongly recommend avoiding round robin DNS as a cost-effective alternative to a hardware load balancer. Client cache expiration policy is entirely uncontrollable, and typical cache expiration times are much longer than desirable periods for node failover. A reverse proxy or software load balancer are recommended alternatives to hardware.
Cache-Based Ticket Registry
The following cache-based ticket storage components provide the best tradeoff among ease of use, scalability, and fault tolerance and are suitable for both active/passive and active/active setups:
- Hazelcast
- EhCache
- JBoss
- MemCached
The particular choice of caching technology should be driven by infrastructure and expertise as much as performance and availability considerations. It’s hardly valuable to have a high-performance cache for which you lack the expertise to troubleshoot when problems invariably arise.
The technology considerations of the various cache components merit some discussion since there are notable differences that impact availability and performance characteristics. Cache systems like Ehcache and JBoss Cache (and its offspring, Infinispan) offer a distributed cache that presents a single, consistent view of entries regardless of the node contacted. Distributed caches rely on replication to provide for consistency. Cache systems like memcached store the ticket on exactly 1 node and use a deterministic algorithm to locate the node containing the ticket:
N’ = f(h(T), N1, N2, N3, … Nm)
where h(T) is the hash of the ticket ID, N1 … Nm is the set of cache nodes, and N’ is member of N … Nm.
These sorts of cache systems do not require replication and generally provide for simplicity at the expense of some durability.
Distributing Service Definitions
In an HA environment, service definitions must be replicated and accessible by all nodes in the CAS cluster. Typically, this may be achieved by leveraging centralized registry implementation that are backed by JPA or LDAP. Registries that are backed by the file system need to devise a process of ensuring proper file replication, either manually or via background daemon.
Connection Pooling
We strongly recommend that all IO connections to a back-end data stores, such as LDAP directories and databases, leverage connection pooling where possible. It makes the best use of computational (especially for SSL/TLS connections) and IO resources while providing the best performance characteristics.
Monitoring
CAS adopters typically implement monitoring of the availability of the CAS service using the tools already in use in operational practice for monitoring other enterprise web applications. CAS introduces a new modest monitoring page with authentication by default by the remote_address of the requestor.
Channel Confidentiality
Channel Confidentiality (via SSL/TLS) is assumed and critical to the security posture of the CAS system. This includes both front-channel (between user browser-agent and CAS server) and back-channel (between web application and CAS server) https traffic, any intermediate proxy traffic between load balancers or content filters and CAS nodes, as well as primary authentication (e.g. LDAPS) and attribute resolution (JDBC over SSL). Any break in the privacy controls at any stage comprises the overall security of the system.
Upgrade/patches/security releases
CAS server upgrades should be carried out through the recommended Maven overlay approach. Established as a best practice, the CAS maven overlay approach allows one to seamlessly obtain the intended CAS server version from well known and public repositories while laying custom changes specific on top of the downloaded binary artifact. In the specifics of the Maven overlay approach, it may also be desirable to externalize the configuration outside of the cas.war so that the properties and logging configuration can vary across tiers for the same cas.war file. That is, externalizing the environment-specific configuration allows the same cas.war to be promoted from server to server and tier to tier, which increases the confidence that the web application that was tested and verified out of production will behave as tested in production.
Upgrade Guide
In general, it is recommended that adopters try to keep their CAS deployment in alignment with the latest CAS version available. In particular, releases that are of PATCH or SECURITY nature should be immediately applied as they are drop-in replacements for their corresponding parent version. See CAS Release Policy for more info.
The general objectives of a CAS upgrade could be:
- Does the upgrade fix a critical security vulnerability or annoying
issue? Is my CAS deployment affected by that vulnerability and/or
bug? - Does the upgrade present features that might be useful to
- Does the upgrade provide functionality that
is carried locally within my overlay, such that by getting rid of
those local changes, I can realize their benefit from CAS directly
and end up with a smaller more-maintainable overlay?
This document attempts to describe, at a very high level, the scope and effort required to upgrade a given CAS Maven overlay. Rather than describing all steps/changes that would be required to review and adjust (which would be impossible), we describe a strategy by which the upgrade could be executed.
Change Log
Before attempting to upgrade, please review the CAS change log to determine what changes/fixes are contained in the version you intend to upgrade to, and whether those are applicable to your environment and your CAS deployment. If you are working with an older CAS version and are experiencing what appears to be a bug, chances are by reviewing the change log, you will find a drop-in replacement for your overlay that takes care of the issue.
Discuss Issue
Having reviewed the change log, if you do not see an improvement that fixes/adjusts the behavior you have in mind, please discuss the issue on the appropriate CAS mailing lists. The result of the discussing would be a scope/effort evaluation to determine feasibility of the solution and the target version in which the fix will be done.
Scope Review
Once you decide your ideal CAS version for the upgrade, before attempting to upgrade, please review the CAS Release Policy. This will provide you with an understanding of what changes you may expect from new version and what the required effort may be for the upgrade.
Evaluate Local Overlay
As a best practice, it is recommended that you deploy CAS via a Maven overlay method. If you have, the task here would be to identify the number of files your overlay has touched and modified. Catalog the what and why of the changes applied, and cross-check those changes with the CAS change log. Chances are, many of the local changes that are present within your overlay are provided by default via CAS as a result of that upgrade which will have you shed many of those improvements locally.
Your changes typically are:
Authentication scheme and strategy (i.e. LDAP, JDBC, etc)
Settings controlling CAS behavior in cas.properties file
User Interface changes may include CSS and JavaScript
Attribute resolution and release policy
Services registered and authorized to use CAS
Prepare Development Environment
Make sure you have a separate development environment ready for configuration and testing. Regardless of how small the upgrade is, you want to make sure it is well tested in your environment before you flip the switch. Evaluate the software dependencies and platform requirements of the new upgrade (i.e. Java, Maven, etc) and make sure you have everything installed and configured correctly before you attempt.
Clean Maven Overlay
We recommend that you first start out with a separate clean CAS Maven overlay targeted at the version to which you want to upgrade. This has the advantage of guaranteeing that your new CAS deployment will be functional without any local changes. Build and deploy the clean CAS overlay once to make sure your build/deployment process is functional.
Apply Changes
Go through your catalog of changes found in your local Maven overlay. Compare and diff those files with their original version. You can find out the delta between two versions via the following ways:
If you have built the clean CAS overlay once, you will automatically get the original version typically in the target directory of CAS overlay. Find the correct file at the correct path, and compare.
Go directly to the project source repository, find the appropriate branch and compare files.
Needless to say, you are going to need:
A decent diff tool, such as KDiff3, WinDiff, Beyond Compare, etc.
A decent intelligent text editor, such as Sublime, Atom or a full blown IDE such as IntelliJ IDEA.
Document Changes
Remember to document the remaining changes that exist within your local overlay, so that the next time you do the same process, you have a clue as for why the overlay looks the way it does.
Maven Overlay Installation
CAS installation is a fundamentally source-oriented process, and we recommend a Maven WAR overlay project to organize customizations such as component configuration and UI design. The output of a Maven WAR overlay build is a cas.war file that can be deployed on a Java servlet container like Tomcat.
A simple Maven WAR overlay project is provided for reference and study: https://github.com/Jasig/cas-overlay-template
The following list of CAS components are those most often customized by deployers:
Authentication handlers (i.e. LdapAuthenticationHandler)
Storage backend (i.e. MemcachedTicketRegistry)
View layer files (JSP/CSS/Javascript)
The first two are controlled by modifying Spring XML configuration files under src/main/webapp/WEB-INF/spring-configuration, the latter by modifying JSP and CSS files under src/main/webapp/WEB-INF/view/jsp/default in the Maven WAR overlay project. Every aspect of CAS can be controlled by adding, removing, or modifying files in the overlay; it’s also possible and indeed common to customize the behavior of CAS by adding third-party components that implement CAS APIs as Java source files or dependency references.
Once an overlay project has been created, the cas.war file must be built and subsequently deployed into a Java servlet container like Tomcat. The following set of commands, issued from the Maven WAR overlay project root directory, provides a sketch of how to accomplish this on a Unix platform.
$CATALINA_HOME/bin/shutdown.sh
mvn clean package
rm -rf $CATALINA_HOME/logs/*
rm -f $CATALINA_HOME/webapps/cas.war
rm -rf $CATALINA_HOME/webapps/cas
rm -rf $CATALINA_HOME/work/*
cp -v target/cas.war $CATALINA_HOME/webapps
$CATALINA_HOME/bin/startup.shConfiguration Files
CAS configuration is controlled primarily by Spring XML context configuration files. At a minimum, every deployer must customize deployerConfigContext.xml and cas.properties by including them in the Maven WAR overlay, but there are other optional configuration files that may be included in the overlay for further customization or to provide additional features. The following exploded file system hierarchy shows how files should be organized in the overlay (1):
\---src
+---main
| +---resources
| | apereo.properties
| | cas-theme-default.properties
| | log4j.xml
| | messages.properties
| | protocol_views.properties
| | saml_views.properties
| | truststore.jks
| |
| \---webapp
| | favicon.ico
| | index.jsp
| |
| +---css
| | cas.css
| |
| +---images
| | cas-logo.png
| | confirm.gif
| | error.gif
| | error.png
| | green.gif
| | info.gif
| | info.png
| | ja-sig-logo.gif
| | jasig-logo-small.png
| | jasig-logo.png
| | key-point_bl.gif
| | key-point_br.gif
| | key-point_tl.gif
| | key-point_tr.gif
| | question.png
| | red.gif
| | success.png
| | warning.png
| |
| +---js
| | cas.js
| |
| +---themes
| | \---apereo
| | +---css
| | | cas.css
| | |
| | +---images
| | | apereo-logo.png
| | | bg-tile.gif
| | |
| | \---js
| | cas.js
| |
| \---WEB-INF
| | cas-servlet.xml
| | cas.properties
| | deployerConfigContext.xml
| | restlet-servlet.xml
| | web.xml
| |
| +---spring-configuration
| | applicationContext.xml
| | argumentExtractorsConfiguration.xml
| | auditTrailContext.xml
| | filters.xml
| | log4jConfiguration.xml
| | propertyFileConfigurer.xml
| | README.txt
| | securityContext.xml
| | ticketExpirationPolicies.xml
| | ticketGrantingTicketCookieGenerator.xml
| | ticketRegistry.xml
| | uniqueIdGenerators.xml
| | warnCookieGenerator.xml
| |
| +---unused-spring-configuration
| | clearpass-configuration.xml
| | lppe-configuration.xml
| | mbeans.xml
| |
| +---view
| | \---jsp
| | | authorizationFailure.jsp
| | | errors.jsp
| | |
| | +---default
| | | \---ui
| | | | casAccountDisabledView.jsp
| | | | casAccountLockedView.jsp
| | | | casBadHoursView.jsp
| | | | casBadWorkstationView.jsp
| | | | casConfirmView.jsp
| | | | casExpiredPassView.jsp
| | | | casGenericSuccess.jsp
| | | | casLoginMessageView.jsp
| | | | casLoginView.jsp
| | | | casLogoutView.jsp
| | | | casMustChangePassView.jsp
| | | | serviceErrorSsoView.jsp
| | | | serviceErrorView.jsp
| | | |
| | | \---includes
| | | bottom.jsp
| | | top.jsp
| | |
| | +---monitoring
| | | viewStatistics.jsp
| | |
| | \---protocol
| | | casPostResponseView.jsp
| | |
| | +---2.0
| | | casProxyFailureView.jsp
| | | casProxySuccessView.jsp
| | | casServiceValidationFailure.jsp
| | | casServiceValidationSuccess.jsp
| | |
| | +---3.0
| | | casServiceValidationFailure.jsp
| | | casServiceValidationSuccess.jsp
| | |
| | +---clearPass
| | | clearPassFailure.jsp
| | | clearPassSuccess.jsp
| | |
| | +---oauth
| | | confirm.jsp
| | |
| | \---openid
| | casOpenIdAssociationFailureView.jsp
| | casOpenIdAssociationSuccessView.jsp
| | casOpenIdServiceFailureView.jsp
| | casOpenIdServiceSuccessView.jsp
| | user.jsp
| |
| \---webflow
| +---login
| | login-webflow.xml
| |
| \---logout
| logout-webflow.xml
|The approach to Spring configuration is to group related components into a single configuration file, which allows deployers to include the handful of files containing components (typically authentication and ticketing) required for their environment. The files are intended to be self-identifying with respect to the kinds of components they contain, with the exception of applicationContext.xml and cas-servlet.xml. For example, auditTrailContext.xml contains components related to the CAS audit trail where events are emitted for successful and failed authentication attempts, among other kinds of auditable events.
It is common practice to exclude cas.properties from the overlay and place it at a well-known filesystem location outside the WAR deployable. In that case, propertyFileConfigurer.xml must be configured to point to the filesystem location of cas.properties. Generally, the Spring XML configuration files under spring-configuration are the most common configuration files, beyond deployerConfigContext.xml, to be included in an overlay. The supplementary Spring configuration files are organized into logically separate configuration concerns that are clearly indicated by the file name.
CAS uses Spring Webflow to drive the login process in a modular and configurable fashion; the login-webflow.xml file contains a straightforward description of states and transitions in the flow. Customizing this file is probably the most common configuration concern beyond component configuration in the Spring XML configuration files. See the Spring Webflow Customization Guide for a thorough description of the various CAS flows and discussion of common configuration points.
Spring Configuration
CAS server depends heavily on the Spring framework. There are exact and specific XML configuration files under spring-configuration directory that control various properties of CAS as well as cas-servlet.xml and deployerConfigContext.xml the latter of which is mostly expected by CAS adopters to be included in the overlay for environment-specific CAS settings.
Spring beans in the XML configuration files can be overwritten to change behavior if need be via the Maven overlay process. There are two approaches to this:
The XML file can be obtained from source for the CAS version and placed at the same exact path by the same exact name in the Maven overlay build. If configured correctly, the build will use the locally-provided XML file rather than the default.
CAS server is able to load patterns of XML configuration files to overwrite what is provided by default. These configuration files that intend to overrule CAS default behavior can be placed at /WEB-INF/ and must be named by the following pattern: cas-servlet-*.xml. Beans placed in this file will overwrite others. This configuration is recognized by the DispatcherServlet in the web.xml file:
<servlet-class>
org.springframework.web.servlet.DispatcherServlet
</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/cas-servlet.xml, /WEB-INF/cas-servlet-*.xml</param-value>
</init-param>Custom and Third-Party Source
It is common to customize or extend the functionality of CAS by developing Java components that implement CAS APIs or to include third-party source by Maven dependency references. Including third-party source is trivial; simply include the relevant dependency in the overlay pom.xml file. In order to include custom Java source, it should be included under a src/java/main directory in the overlay project source tree.
├── src
│ ├── main
│ │ ├── java
│ │ │ └── edu
│ │ │ └── vt
│ │ │ └── middleware
│ │ │ └── cas
│ │ │ ├── audit
│ │ │ │ ├── CompactSlf4jAuditTrailManager.java
│ │ │ │ ├── CredentialsResourceResolver.java
│ │ │ │ ├── ServiceResourceResolver.java
│ │ │ │ └── TicketOrCredentialPrincipalResolver.java
│ │ │ ├── authentication
│ │ │ │ └── principal
│ │ │ │ ├── AbstractCredentialsToPrincipalResolver.java
│ │ │ │ ├── PDCCredentialsToPrincipalResolver.java
│ │ │ │ └── UsernamePasswordCredentialsToPrincipalResolver.java
│ │ │ ├── services
│ │ │ │ └── JsonServiceRegistryDao.java
│ │ │ ├── util
│ │ │ │ └── X509Helper.java
│ │ │ └── web
│ │ │ ├── HelpController.java
│ │ │ ├── RegisteredServiceController.java
│ │ │ ├── StatsController.java
│ │ │ ├── WarnController.java
│ │ │ ├── flow
│ │ │ │ ├── AbstractForgottenCredentialAction.java
│ │ │ │ ├── AbstractLdapQueryAction.java
│ │ │ │ ├── AffiliationHandlerAction.java
│ │ │ │ ├── CheckAccountRecoveryMaintenanceAction.java
│ │ │ │ ├── CheckPasswordExpirationAction.java
│ │ │ │ ├── ForgottenCredentialTypeAction.java
│ │ │ │ ├── LookupRegisteredServiceAction.java
│ │ │ │ ├── NoSuchFlowHandler.java
│ │ │ │ ├── User.java
│ │ │ │ ├── UserLookupAction.java
│ │ │ │ └── WarnCookieHandlerAction.java
│ │ │ └── util
│ │ │ ├── ProtocolParameterAuthority.java
│ │ │ ├── UriEncoder.java
│ │ │ └── UrlBuilder.javaAlso, note that for any custom Java component to compile and be included in the final cas.war file, the pom.xml in the Maven overlay must include a reference to the Maven Java compiler so classes can compiled. Here is a sample build configuration:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<warName>cas</warName>
<overlays>
<overlay>
<groupId>org.jasig.cas</groupId>
<artifactId>cas-server-webapp</artifactId>
<excludes>
<exclude>WEB-INF/cas.properties</exclude>
<exclude>WEB-INF/classes/log4j.xml</exclude>
<exclude>...</exclude>
</excludes>
</overlay>
</overlays>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>${java.source.version}</source>
<target>${java.target.version}</target>
</configuration>
</plugin>
</plugins>
<finalName>cas</finalName>
</build>
Authentication
The CAS authentication process is performed by several related components:
PrincipalNameTransformer
Transforms the user id string that is typed into the login form into a tentative Principal Name to be validated by a specific type of Authentication Handler.
AuthenticationManager
Entry point into authentication subsystem. It accepts one or more credentials and delegates authentication to configured AuthenticationHandler components. It collects the results of each attempt and determines effective security policy.
AuthenticationHandler
Authenticates a single credential and reports one of three possible results: success, failure, not attempted.
PrincipalResolver
Converts information in the authentication credential into a security principal that commonly contains additional metadata attributes (i.e. user details such as affiliations, group membership, email, display name).
AuthenticationMetaDataPopulator
Strategy component for setting arbitrary metadata about a successful authentication event; these are commonly used to set protocol-specific data.
Unless otherwise noted, the configuration for all authentication components is handled in deployerConfigContext.xml.
Authentication Manager
CAS ships with a single yet flexible authentication manager, PolicyBasedAuthenticationManager, that should be sufficient for most needs. It performs authentication according to the following contract.
For each given credential do the following:
Iterate over all configured authentication handlers.
Attempt to authenticate a credential if a handler supports it.
On success attempt to resolve a principal.
Check whether a resolver is configured for the handler that authenticated the credential.
If a suitable resolver is found, attempt to resolve the principal.
If a suitable resolver is not found, use the principal resolved by the authentication handler.
Check whether the security policy (e.g. any, all) is satisfied.
If security policy is met return immediately.
Continue if security policy is not met.
After all credentials have been attempted check security policy again and throw AuthenticationException if not satisfied.
There is an implicit security policy that requires at least one handler to successfully authenticate a credential, but the behavior can be further controlled by setting #setAuthenticationPolicy(AuthenticationPolicy) with one of the following policies.
AnyAuthenticationPolicy
Satisfied if any handler succeeds. Supports a tryAll flag to avoid short circuiting at step 4.1 above and try every handler even if one prior succeeded. This policy is the default and provides backward-compatible behavior with the AuthenticationManagerImpl component of CAS 3.x.
AllAuthenticationPolicy
Satisfied if and only if all given credentials are successfully authenticated. Support for multiple credentials is new in CAS and this handler would only be acceptable in a multi-factor authentication situation.
RequiredHandlerAuthenticationPolicy
Satisfied if an only if a specified handler successfully authenticates its credential. Supports a tryAll flag to avoid short circuiting at step 4.1 above and try every handler even if one prior succeeded. This policy could be used to support a multi-factor authentication situation, for example, where username/password authentication is required but an additional OTP is optional.
The following configuration snippet demonstrates how to configure PolicyBasedAuthenticationManager for a straightforward multi-factor authentication case where username/password authentication is required and an additional OTP credential is optional; in both cases principals are resolved from LDAP.
<bean id="passwordHandler"
class="org.jasig.cas.authentication.LdapAuthenticationHandler">
<!-- Details elided for simplicity -->
</bean>
<bean id="oneTimePasswordHandler"
class="com.example.cas.authentication.CustomOTPAuthenticationHandler"
p:name="oneTimePasswordHandler" />
<bean id="authenticationPolicy"
class="org.jasig.cas.authentication.RequiredHandlerAuthenticationPolicyFactory"
c:requiredHandlerName="passwordHandler"
p:tryAll="true" />
<bean id="principalResolver"
class="org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver"
p:principalAttributeName="username"
p:attributeRepository-ref="attributeRepository"
p:returnNullIfNoAttributes="true" />
<bean id="authenticationManager"
class="org.jasig.cas.authentication.PolicyBasedAuthenticationManager"
p:authenticationPolicy-ref="authenticationPolicy">
<constructor-arg>
<map>
<entry key-ref="passwordHandler" value-ref="principalResolver"/>
<entry key-ref="oneTimePasswordHandler" value-ref="principalResolver" />
</map>
</constructor-arg>
<property name="authenticationMetaDataPopulators">
<list>
<bean class="org.jasig.cas.authentication.SuccessfulHandlerMetaDataPopulator" />
</list>
</property>
</bean>Authentication Handlers
CAS ships with support for authenticating against many common kinds of authentication systems. The following list provides a complete list of supported authentication technologies; jump to the section(s) of interest.
- Database
- JAAS
- LDAP
- Legacy OAuth 1.0/2.0, OpenID
- RADIUS
- SPNEGO(Windows)
- Trusted (REMOTE_USER)
- X.509 (client SSL certificate)
- Remote Address
There are some additional handlers for small deployments and special cases:
- Whilelist
- Blacklist
Argument Extractors
Extractors are responsible to examine the http request received for parameters that describe the authentication request such as the requesting service, etc. Extractors exist for a number of supported authentication protocols and each create appropriate instances of WebApplicationService that contains the results of the extraction.
Argument extractor configuration is defined at src/main/webapp/WEB-INF/spring-configuration/argumentExtractorsConfiguration.xml. Here’s a brief sample:
<bean id="casArgumentExtractor" class="org.jasig.cas.web.support.CasArgumentExtractor" />
<util:list id="argumentExtractors">
<ref bean="casArgumentExtractor" />
</util:list>Components
ArgumentExtractor
Strategy parent interface that defines operations needed to extract arguments from the http request.
CasArgumentExtractor
Argument extractor that maps the request based on the specifications of the CAS protocol.
GoogleAccountsArgumentExtractor
Argument extractor to be used to enable Google Apps integration and SAML v2 specification.
SamlArgumentExtractor
Argument extractor compliant with SAML v1.1 specification.
OpenIdArgumentExtractor
Argument extractor compliant with OpenId protocol.
Principal Resolution
PrincipalNameTransformer Components
Authentication handlers that generally deal with username-password credentials can be configured to transform the user id prior to executing the authentication sequence. The following components are available:
NoOpPrincipalNameTransformer
Default transformer, that actually does no transformation on the user id.
PrefixSuffixPrincipalNameTransformer
Transforms the user id by adding a postfix or suffix.
ConvertCasePrincipalNameTransformer
A transformer that converts the form uid to either lowercase or uppercase. The result is also trimmed. The transformer is also able to accept and work on the result of a previous transformer that might have modified the uid, such that the two can be chained.
Configuration
Here is an example configuration based for the AcceptUsersAuthenticationHandler:
<bean id="primaryAuthenticationHandler"
class="org.jasig.cas.authentication.AcceptUsersAuthenticationHandler"
p:principalNameTransformer-ref="convertCasePrincipalNameTransformer">
<property name="users">
<map>
<entry key="casuser" value="Mellon"/>
</map>
</property>
</bean>
<bean id="convertCasePrincipalNameTransformer"
class="org.jasig.cas.authentication.handler.ConvertCasePrincipalNameTransformer"
p:toUpperCase="true" />Authentication Metadata
AuthenticationMetaDataPopulator components provide a pluggable strategy for injecting arbitrary metadata into the authentication subsystem for consumption by other subsystems or external components. Some notable uses of metadata populators:
Supports the long term authentication feature
SAML protocol support
OAuth and OpenID protocol support.
The default authentication metadata populators should be sufficient for most deployments. Where the components are required to support optional CAS features, they will be explicitly identified and configuration will be provided.
Long Term Authentication
CAS has support for long term Ticket Granting Tickets, a feature that is also referred to as “Remember Me” to extends the length of the SSO session beyond the typical configuration. Please see this guide for more details.
Proxy Authentication
Please see this guide for more details.
Multi-factor Authentication (MFA)
Please see this guide for more details.
Login Throttling
CAS provides a facility for limiting failed login attempts to support password guessing and related abuse scenarios. Please see this guide for additional details on login throttling.
SSO Session Cookie
A ticket-granting cookie is an HTTP cookie set by CAS upon the establishment of a single sign-on session. This cookie maintains login state for the client, and while it is valid, the client can present it to CAS in lieu of primary credentials. Please see this guide for additional details.
Configuring Ticketing Components
There are two core configurable ticketing components:
TicketRegistry - Provides for durable ticket storage.
ExpirationPolicy - Provides a policy framework for ticket expiration semantics.
Ticket Registry
The deployment environment and technology expertise generally determine the particular TicketRegistry component. A cache-backed implementation is recommended for HA deployments, while the default DefaultTicketRegistry in-memory component may be suitable for small deployments.
Default (In-Memory) Ticket Registry
DefaultTicketRegistry uses a ConcurrentHashMap for memory-backed ticket storage and retrieval. This component does not preserve ticket state across restarts. There are a few configuration knobs available:
initialCapacity - ConcurrentHashMap initial capacity.
loadFactor - ConcurrentHashMap load factor.
concurrencyLevel - Allows tuning the ConcurrentHashMap for concurrent write support.
All three arguments map to those of the ConcurrentHashMap constructor.
<bean id="ticketRegistry"
class="org.jasig.cas.ticket.registry.DefaultTicketRegistry"
c:initialCapacity="10000"
c:loadFactor="1"
c:concurrencyLevel="20" />Cache-Based Ticket Registries
Cached-based ticket registries provide a high-performance solution for ticket storage in high availability deployments. Components for the following caching technologies are provided:
RDBMS Ticket Registries
RDBMS-based ticket registries provide a distributed ticket store across multiple CAS nodes. Components for the following caching technologies are provided:
JPA
Ticket Generators
CAS presents a pluggable architecture for generating unique ticket ids for each ticket type. The configuration of each generator is defined at src\main\webapp\WEB-INF\spring-configuration\uniqueIdGenerators.xml. Here’s a brief sample:
<bean id="ticketGrantingTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
c:maxLength="50" c:suffix="${host.name}" />
<bean id="serviceTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
c:maxLength="20" c:suffix="${host.name}" />
<bean id="loginTicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
c:maxLength="30" c:suffix="${host.name}" />
<bean id="proxy20TicketUniqueIdGenerator" class="org.jasig.cas.util.DefaultUniqueTicketIdGenerator"
c:maxLength="20" c:suffix="${host.name}" />
<util:map id="uniqueIdGeneratorsMap">
<entry
key="org.jasig.cas.authentication.principal.SimpleWebApplicationServiceImpl"
value-ref="serviceTicketUniqueIdGenerator" />
</util:map>Components
UniqueTicketIdGenerator
Strategy parent interface that describes operations needed to generate a unique id for a ticket.
DefaultUniqueTicketIdGenerator
Uses numeric and random string generators to create a unique id, while supporting prefixes for each ticket type, as is outlined by the CAS protocol, as well as a suffix that typically is mapped to the CAS server node identifier in order to indicate which node is the author of this ticket. The latter configuration point helps with troubleshooting and diagnostics in a clustered CAS environment.
HostNameBasedUniqueTicketIdGenerator
An extension of DefaultUniqueTicketIdGenerator that is able auto-configure the suffix based on the underlying host name. In order to assist with multi-node deployments, in scenarios where CAS configuration and specially cas.properties file is externalized, it would be ideal to simply just have one set of configuration files for all nodes, such that there would for instance be one cas.properties file for all nodes. This would remove the need to copy/sync configuration files over across nodes, again in a situation where they are externalized.
The drawback is that in keeping only one cas.properties file, we’d lose the ability to define unique host.name property values for each node as the suffix, which would assist with troubleshooting and diagnostics. To provide a remedy, this ticket generator is able to retrieve the host.name value directly from the actual node name, rather than relying on the configuration, only if one isn’t specified in the cas.properties file.
SamlCompliantUniqueTicketIdGenerator
Unique Ticket Id Generator compliant with the SAML 1.1 specification for artifacts, that is also compliant with the SAML v2 specification.
Ticket Registry Cleaner
The ticket registry cleaner should be used for ticket registries that cannot manage their own state. That would include the default in-memory registry and the JPA ticket registry. Cache-based ticket registry implementations such as Memcached, Hazelcast or Ehcache do not require a registry cleaner. The ticket registry cleaner configuration is specified in the spring-configuration/ticketRegistry.xml file.
Components
RegistryCleaner
Strategy interface to denote the start of cleaning the registry.
DefaultTicketRegistryCleaner
The default ticket registry cleaner scans the entire CAS ticket registry for expired tickets and removes them. This process is only required so that the size of the ticket registry will not grow beyond a reasonable size. The functionality of CAS is not dependent on a ticket being removed as soon as it is expired. Locking strategies may be used to support high availability environments. In a clustered CAS environment with several CAS nodes executing ticket cleanup, it is desirable to execute cleanup from only one CAS node at a time.
LockingStrategy
Strategy pattern for defining a locking strategy in support of exclusive execution of some process.
NoOpLockingStrategy
No-Op locking strategy that allows the use of DefaultTicketRegistryCleaner in environments where exclusive access to the registry for cleaning is either unnecessary or not possible.
Configuration
If you’re using the default ticket registry configuration, your /cas-server-webapp/WEB-INF/spring-configuration/ticketRegistry.xml probably looks like this:
<!-- TICKET REGISTRY CLEANER -->
<bean id="ticketRegistryCleaner"
class="org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner"
c:centralAuthenticationService-ref="centralAuthenticationService"
c:ticketRegistry-ref="ticketRegistry"/>
<bean id="jobDetailTicketRegistryCleaner"
class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean"
p:targetObject-ref="ticketRegistryCleaner"
p:targetMethod="clean" />
<bean id="triggerJobDetailTicketRegistryCleaner"
class="org.springframework.scheduling.quartz.SimpleTriggerFactoryBean"
p:jobDetail-ref="jobDetailTicketRegistryCleaner"
p:startDelay="20000"
p:repeatInterval="5000000" />Ticket Expiration Policies
CAS supports a pluggable and extensible policy framework to control the expiration policy of ticket-granting tickets (TGT) and service tickets (ST). See this guide for details on how to configure the expiration policies.
Logout and Single Logout (SLO)
There are potentially many active application sessions during a CAS single sign-on session, and the distinction between logout and single logout is based on the number of sessions that are ended upon a logout operation. The scope of logout is determined by where the action takes place:
Application logout - ends a single application session
CAS logout - ends the CAS SSO session
Note that the logout action in each case has no effect on the other in the simple case. Ending an application session does not end the CAS session and ending the CAS session does not affect application sessions. This is a common cause of confusion for new users and deployers of an SSO system.
The single logout support in CAS attempts to reconcile the dispartity between CAS logout and application logout. When CAS is configured for SLO, it attempts to send logout messages to every application that requested authentication to CAS during the SSO session. While this is a best-effort process, in many cases it works well and provides a consistent user experience by creating symmetry between login and logout.
CAS Logout
Per the CAS Protocol, the /logout endpoint is responsible for destroying the current SSO session. Upon logout, it may also be desirable to redirect back to a service. This is controlled via specifying the redirect link via the service parameter.
The redirect behavior is turned off by default, and is activated via the following setting in cas.properties:
# Specify whether CAS should redirect to the specified service parameter on /logout requests
# cas.logout.followServiceRedirects=falseThe specified url must be registered in the service registry of CAS and enabled.
Single Logout (SLO)
CAS is designed to support single sign out: it means that it will be able to invalidate client application sessions in addition to its own SSO session.
Whenever a ticket-granting ticket is explicitly expired, the logout protocol will be initiated. Clients that do not support the logout protocol may notice extra requests in their access logs that appear not to do anything.
Usage Warning!
Single Logout is turned on by default.
When a CAS session ends, it notifies each of the services that the SSO session is no longer valid, and that relying parties need to invalidate their own session.
This can happen in two ways:
CAS sends an HTTP POST message directly to the service ( back channel communication): this is the traditional way of performing notification to the service.
CAS redirects (HTTP 302) to the service with a message and a RelayState parameter (front channel communication): This feature is inspired by SAML SLO, and is needed if the client application is composed of several servers and use session affinity. The expected behaviour of the CAS client is to invalidate the application web session and redirect back to the CAS server with the RelayState parameter.
Usage Warning!
Front-channel SLO at this point is still experimental.
SLO Requests
The way the notification is done (back or front channel) is configured at a service level through the logoutType property. This value is set to LogoutType.BACK_CHANNEL by default. The message is delivered or the redirection is sent to the URL presented in the service parameter of the original CAS protocol ticket request.
A sample SLO message:
<samlp:LogoutRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="[RANDOM ID]"
Version="2.0"
IssueInstant="[CURRENT DATE/TIME]">
<saml:NameID>@NOT_USED@</saml:NameID>
<samlp:SessionIndex>[SESSION IDENTIFIER]</samlp:SessionIndex>
</samlp:LogoutRequest>The session identifier is the CAS service ticket ID that was provided to the service when it originally authenticated to CAS. The session identifier is used to correlate a CAS session with an application session; for example, the SLO session identifier maps to a servlet session that can subsequently be destroyed to terminate the application session.
Logout protocol is effectively managed by the LogoutManagerImpl component:
<bean id="logoutManager" class="org.jasig.cas.logout.LogoutManagerImpl"
c:servicesManager-ref="servicesManager"
c:httpClient-ref="noRedirectHttpClient"
c:logoutMessageBuilder-ref="logoutBuilder"
p:singleLogoutCallbacksDisabled="${slo.callbacks.disabled:false}"
p:asynchronous="${slo.callbacks.asynchronous:true}"/>Turning Off Single Logout
To disable single logout, adjust the following setting in cas.properties file:
# To turn off all back channel SLO requests set slo.disabled to true
# slo.callbacks.disabled=falseSingle Logout Per Service
Registered applications with CAS have the option to control single logout behavior individually via the Service Managament component. Each registered service in the service registry will include configuration that describes how to the logout request should be submitted. This behavior is controlled via the logoutType property which allows to specify whether the logout request should be submitted via back/front channel or turned off for this application.
Sample configuration follows:
{
"@class" : "org.jasig.cas.services.RegexRegisteredService",
"serviceId" : "testId",
"name" : "testId",
"id" : 1,
"logoutType" : "BACK_CHANNEL"
}Service Endpoint for Logout Requests
By default, logout requests are submitted to the original service id. CAS has the option to submit such requests to a specific service endpoint that is different from the original service id, and of course can be configured on a per-service level. This is useful in cases where the application that is integrated with CAS does not exactly use a CAS client that supports intercepting such requests and instead, exposes a different endpoint for its logout operations.
To configure a service specific endpoint, try the following example:
{
"@class" : "org.jasig.cas.services.RegexRegisteredService",
"serviceId" : "testId",
"name" : "testId",
"id" : 1,
"logoutType" : "BACK_CHANNEL",
"logoutUrl" : "https://web.application.net/logout",
}Aynchronous SLO Messages
By default, backchannel logout messages are sent to endpoint in an asynchronous fashion. To allow synchronous messages, modify the following setting in cas.properties:
# To send callbacks to endpoints synchronously, set this to false
# slo.callbacks.asynchronous=trueTicket Registry Cleaner Behavior
Furthermore, the default behavior is to issue single sign out callbacks in response to a logout request or when a TGT is expired via expiration policy when a TicketRegistryCleaner runs. If you are using ticket registry cleaner and you want to enable the single sign out callback only when CAS receives a logout request, you can configure your TicketRegistryCleaner as such:
<bean id="ticketRegistryCleaner"
class="org.jasig.cas.ticket.registry.support.DefaultTicketRegistryCleaner"
c:centralAuthenticationService-ref="centralAuthenticationService"
c:ticketRegistry-ref="ticketRegistry"
p:lock-ref="cleanerLock"/>
With TicketRegistryCleaner
- Single Logout is turned on
- The cleaner runs to detect the ticket
that are automatically expired. It will query the tickets in the
ticket registry, and will accumulate those that are expired. - For the collection of expired tickets, the cleaner will again ask them to
“expire” which triggers the SLO callback to be issued. The cleaner
subsequently removes the TGT from the registry. - Note that simplyremoving a ticket by itself from the registry does not issue the SLO
callback. A ticket needs to be explicitly told one way or another,
to “expire” itself: If the ticket is already expired, the mechanism
will issue the SLO callback. If the ticket is not already expired,
it will be marked as expired and the SLO callback will be issued.
Without TicketRegistryCleaner
1.Single Logout is turned on
2.There is no cleaner, so nothing runs in the background or otherwise to “expire” and delete tickets from the registry and thus, no SLO callbacks will be issued automatically.
3.A logout request is received by CAS
4.CAS will locate the TGT and will attempt to destroy the SSO session.
5.In destroying the ticket, CAS will:
Ask the ticket to expire itself, which will issue SLO callbacks.
Delete the ticket from the registry
SSO Session vs. Application Session
In order to better understand the SSO session management of CAS and how it regards application sessions, one important note is to be first and foremost considered:
CAS is NOT a session manager
Application session is the responsibility of the application.
CAS wants to maintain and control the SSO session in the form of the TicketGrantingTicket and a TGT id which is shared between the user-agent and the CAS server in the form of a secure cookie.
CAS is not an application session manager in that it is the responsibility of the applications to maintain and control their own application sessions. Once authentication is completed, CAS is typically out of the picture in terms of the application sessions. Therefore, the expiration policy of the application session itself is entirely independent of CAS and may be loosely coordinated and adjusted depending on the ideal user experience in the event that the application session expires.
In the event that Single Logout is not activated, typically, application may expose a logout endpoint in order to destroy the session and next, redirect the agent to the CAS logout endpoint in order to completely destroy the SSO session as well.
Here’s a brief diagram that demonstrates various application session configuration and interactions with CAS:
1277
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
