From d3d5ed9ad5cd1a494fe1b5989c78388d24a6653c Mon Sep 17 00:00:00 2001 From: Misagh Moayyed Date: Wed, 27 Jul 2016 11:53:30 -0700 Subject: [PATCH] Doc updates --- .../Configuring-Service-Access-Strategy.md | 2 +- .../installation/Logout-Single-Signout.md | 13 +- .../installation/SPNEGO-Authentication.md | 2 +- .../installation/Troubleshooting-Guide.md | 3 +- .../Webflow-Customization-Sessions.md | 2 +- .../integration/Attribute-Resolution.md | 2 +- .../planning/Architecture.md | 2 +- .../planning/High-Availability-Guide.md | 140 ++++++++++++++---- .../planning/Installation-Requirements.md | 2 +- .../planning/Security-Guide.md | 4 +- 10 files changed, 128 insertions(+), 44 deletions(-) diff --git a/cas-server-documentation/installation/Configuring-Service-Access-Strategy.md b/cas-server-documentation/installation/Configuring-Service-Access-Strategy.md index f42d8d60f282..92d9c2951ce4 100644 --- a/cas-server-documentation/installation/Configuring-Service-Access-Strategy.md +++ b/cas-server-documentation/installation/Configuring-Service-Access-Strategy.md @@ -65,7 +65,7 @@ The `GrouperRegisteredServiceAccessStrategy` is enabled by including the followi ``` This access strategy attempts to locate [Grouper](https://www.internet2.edu/products-services/trust-identity-middleware/grouper/) groups for the CAS principal. The groups returned by Grouper -are collected as CAS attribtues and examined against the list of required attributes for service access. +are collected as CAS attributes and examined against the list of required attributes for service access. The following properties are available: diff --git a/cas-server-documentation/installation/Logout-Single-Signout.md b/cas-server-documentation/installation/Logout-Single-Signout.md index dfd93f4920d9..4ee29f8ec28d 100644 --- a/cas-server-documentation/installation/Logout-Single-Signout.md +++ b/cas-server-documentation/installation/Logout-Single-Signout.md @@ -16,7 +16,7 @@ Note that the logout action in each case has no effect on the other in the simpl 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 +The single logout support in CAS attempts to reconcile the disparity 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. @@ -80,7 +80,11 @@ To disable single logout, adjust the following setting in `application.propertie ``` ### Single Logout Per Service -Registered applications with CAS have the option to control single logout behavior individually via the [Service Managament](Service-Management.html) 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. + +Registered applications with CAS have the option to control single logout behavior individually via +the [Service Management](Service-Management.html) 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: @@ -112,8 +116,9 @@ To configure a service specific endpoint, try the following example: } ``` -### 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 `application.properties`: +### Asynchronous SLO Messages +By default, backchannel logout messages are sent to endpoint in an asynchronous fashion. To allow synchronous messages, +modify the following setting in `application.properties`: ```bash # To send callbacks to endpoints synchronously, set this to false diff --git a/cas-server-documentation/installation/SPNEGO-Authentication.md b/cas-server-documentation/installation/SPNEGO-Authentication.md index 48c1a1e49ad0..b0b268e96ffb 100644 --- a/cas-server-documentation/installation/SPNEGO-Authentication.md +++ b/cas-server-documentation/installation/SPNEGO-Authentication.md @@ -23,7 +23,7 @@ ticket expires. ## Requirements * Client is logged in to a Windows Active Directory domain. -* Supported browser and JDK. +* Supported browser. * CAS is running MIT kerberos against the AD domain controller. ## Components diff --git a/cas-server-documentation/installation/Troubleshooting-Guide.md b/cas-server-documentation/installation/Troubleshooting-Guide.md index 0ed2e3fa3384..a9e40dac5734 100644 --- a/cas-server-documentation/installation/Troubleshooting-Guide.md +++ b/cas-server-documentation/installation/Troubleshooting-Guide.md @@ -21,7 +21,8 @@ You may encounter this error, when the requesting application/service url cannot Please [review this guide](Service-Management.html) to better understand the CAS service registry. ## Invalid/Expired CAS Tickets -You may experience `INVAILD_TICKET` related errors when attempting to use a CAS ticet whose expiration policy dictates that the ticket has expired. The CAS log should further explain in more detail if the ticket is considered expired, but for diagnostic purposes, you may want to adjust the [ticket expiration policy configuration](Configuring-Ticket-Expiration-Policy.html) to remove and troubleshoot this error. +You may experience `INVAILD_TICKET` related errors when attempting to use a CAS ticket whose expiration policy dictates that the ticket +has expired. The CAS log should further explain in more detail if the ticket is considered expired, but for diagnostic purposes, you may want to adjust the [ticket expiration policy configuration](Configuring-Ticket-Expiration-Policy.html) to remove and troubleshoot this error. Furthermore, if the ticket itself cannot be located in the CAS ticket registry the ticket is also considered invalid. You will need to observe the ticket used and compare it with the value that exists in the ticket registry to ensure that the ticket id provided is valid. diff --git a/cas-server-documentation/installation/Webflow-Customization-Sessions.md b/cas-server-documentation/installation/Webflow-Customization-Sessions.md index 4d127c517fd1..fd6304534fbf 100644 --- a/cas-server-documentation/installation/Webflow-Customization-Sessions.md +++ b/cas-server-documentation/installation/Webflow-Customization-Sessions.md @@ -39,7 +39,7 @@ To see the relevant list of CAS properties, please [review this guide](Configura Doing so will likely require you to also enable sticky sessions and/or session replication in a clustered deployment of CAS. -### Hazelast Session Replication +### Hazelcast Session Replication If you don't wish to use the native container's strategy for session replication, you can use CAS's support for Hazelcast session replication. diff --git a/cas-server-documentation/integration/Attribute-Resolution.md b/cas-server-documentation/integration/Attribute-Resolution.md index ecf49dcf3e43..c6af13d5c35b 100644 --- a/cas-server-documentation/integration/Attribute-Resolution.md +++ b/cas-server-documentation/integration/Attribute-Resolution.md @@ -108,7 +108,7 @@ The module provides a `shibbolethPersonAttributeDao` that the Shibboleth's `attr - Modify either `application.properties` or the runtime environment to reference the `attribute-resolver.xml` resource via a property. This is a -comma seperated list of resources to use for the configuration: +comma separated list of resources to use for the configuration: ```shell -Dcas.shibAttributeResolver.resources=classpath:attribute-resolver.xml diff --git a/cas-server-documentation/planning/Architecture.md b/cas-server-documentation/planning/Architecture.md index bf1be4685505..8ee9b5e2b2b2 100644 --- a/cas-server-documentation/planning/Architecture.md +++ b/cas-server-documentation/planning/Architecture.md @@ -87,7 +87,7 @@ CAS uses the many aspects of the Spring Framework; most notably, [Spring Webflow](http://www.springsource.org/spring-web-flow). 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 +some framework components, 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](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) diff --git a/cas-server-documentation/planning/High-Availability-Guide.md b/cas-server-documentation/planning/High-Availability-Guide.md index 12da8052b3c0..ca7b7267e727 100644 --- a/cas-server-documentation/planning/High-Availability-Guide.md +++ b/cas-server-documentation/planning/High-Availability-Guide.md @@ -6,13 +6,26 @@ title: CAS - High Availability Guide # 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. +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. +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. +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. +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 @@ -26,7 +39,7 @@ It's worth pointing out some important characteristics of this architecture: * 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. +* Loss of SSO state data is always graceful: users simply re-authenticate. Before proceeding into a detailed discussion of various aspects of the recommended architecture, we offer a guiding principle for planning a highly available deployment: @@ -40,27 +53,46 @@ 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. +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. +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. +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. +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. +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](../installation/Configuring-Ticketing-Components.html) for implementing an active-active configuration with shared ticket state. +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](../installation/Configuring-Ticketing-Components.html) +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. +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: @@ -72,21 +104,36 @@ Multi-node CAS generally involves the following: #### 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 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. +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. +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: +Maintenance work, such that it would include upgrades and application of patches to the +software may be carried out via two general approaches: -1. 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-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. -2. 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. +- 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 @@ -94,15 +141,19 @@ 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 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. +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 re-authenticate to CAS to create new SSO sessions; +CAS client sessions created under previous SSO sessions would suffer no interruption 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. +A load balancer in active/active mode serves requests to all N nodes simultaneously. 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: @@ -114,11 +165,18 @@ Since both requests flow through the load balancer from different source address 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. +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](https://github.com/serac/spring-webflow-client-repo) components, such configurations at present have not been proven and are not recommended without careful planning and testing. +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](https://github.com/serac/spring-webflow-client-repo) components, such configurations +at present have not been proven and are not recommended without careful planning and testing. #### Avoid Round Robin DNS @@ -162,22 +220,42 @@ so that tickets are encrypted and signed on replication attempts to prevent snif ### 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. + +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. +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. + +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. + +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. + +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. diff --git a/cas-server-documentation/planning/Installation-Requirements.md b/cas-server-documentation/planning/Installation-Requirements.md index 6125fb2eef13..b7345cec720e 100644 --- a/cas-server-documentation/planning/Installation-Requirements.md +++ b/cas-server-documentation/planning/Installation-Requirements.md @@ -46,7 +46,7 @@ benefits in the long run 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. +behavior by altering 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 diff --git a/cas-server-documentation/planning/Security-Guide.md b/cas-server-documentation/planning/Security-Guide.md index 7c2c5b9b344b..0500e3dd5c0f 100644 --- a/cas-server-documentation/planning/Security-Guide.md +++ b/cas-server-documentation/planning/Security-Guide.md @@ -34,7 +34,7 @@ Practically, it means that all CAS urls must use HTTPS, but it **also** means th 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 unnecessary. Private networks and corporate networks with strict -acces controls are common exceptions, but secure transport is recommended nonetheless. +access 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. @@ -49,7 +49,7 @@ 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_ +re-authenticate 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