CAS 5.2.x Deployment - WAR Overlays

This is a short and sweet tutorial on how to deploy CAS via the WAR Overlay method.

This tutorial specifically requires and focuses on:

  • CAS 5.2.x
  • Java 8
Need Help?
If you ever get stuck and are in need of additional assistance, start by reviewing the suggestions provided here. You may also look at available support options provided here.


Overlays are a strategy to combat repetitive code and/or resources. Rather than downloading the CAS codebase and building it from source, overlays allow you to download a pre-built vanilla CAS web application server provided by the project itself, override/insert specific behavior into it and then merge it all back together to produce the final (web application) artifact. You can find a lot more about how overlays work here.

The concept of the WAR Overlay is NOT a CAS invention. It’s specifically an Apache Maven feature and of course, there are techniques and plugins available to apply the same concept to Gradle-based builds as well.You are free to choose between Maven or Gradle. For this tutorial, I opted into the Maven WAR overlay.

Once you have forked and cloned the repository locally, you’re ready to begin.

Remember to switch to the appropriate branch. Today, the master branch of the repository applies to CAS 5.2.x deployments. That may not necessarily remain true when you start your own deployment. So examine the branches and make sure you checkout the one matching your intended CAS version.

Overlay’s Anatomy

Similar to Grey’s, a Maven WAR overlay is composed of several facets the most important of which is the pom.xml file. This is a build descriptor file whose job is to teach Apache Maven how to obtain, build, configure (and in certain cases deploy) artifacts.

You do not need to download Apache Maven separately. The project provides one for you automatically with the embedded Maven Wrapper.

The pom.xml is composed of several sections. The ones you need to worry about are the following.



This is the bit that describes build settings, and specifically, here, what versions of CAS, Spring Boot, and Java are required for the deployment. You are in practice mostly concerned with the <cas.version> setting and as new (maintenance) releases come out, it would be sufficient to simply update that version and re-run the build.

This might be a good time to review the CAS project’s Release Policy as well as Maintenance Policy.


The next piece describes the dependencies of the overlay build. These are the set of components almost always provided by the CAS project that will be packaged up and put into the final web application artifact. At a minimum, you need to have the cas-server-webapp-${app.server} module available because that is the web application into which you intend to inject your settings and customizations if any. Also, note that the module declarations are typically configured to download the CAS version instructed by the property ${cas.version}.

Here is an example:


Including a CAS module/dependency in the pom.xml simply advertises to CAS your intention of turning on a new feature or a variation of a current behavior. Do NOT include something in your build just because it looks and sounds cool. Remember that the point of an overlay is to only keep track of things you actually need and care about, and no more.

Keep your build clean and tidy. A messy build often leads to a messy deployment, complicates your upgrade path and is a documented cause of early hair loss. Keep changes down to the absolute essentials and document their need for your deployment. If you review the configuration a year from now, you should have an idea of why things are the way they are.

And What About…?

There are many other pieces in the pom.xml, such as repositories, profiles, plugins, etc that I skipped. For everything else, there is MasterCard…and of course the official Apache Maven guides. Enjoy!

The Build

Now that you have a basic understanding of the build descriptor, it’s time to actually run the build. An Apache Maven build is often executed by passing specific goals/commands to Apache Maven itself, aka mvn. So for instance in the terminal and once inside the project directory you could execute things like:

cd cas-overlay-template
mvn clean

…which may be a problem if you don’t have already have Apache Maven downloaded and installed. While you can do that separate install, the WAR Overlay project provides you with an embedded Apache Maven instance whose job is to first determine whether you have Maven installed and if not, download and configure one for you based on the project’s needs. So you can replace that command above with:

cd cas-overlay-template
mvnw clean

…which may be a problem because, how are you supposed to know what commands/goals can be passed to the build? You can study them for sure, but the project provides you with a shell script that wraps itself around the Maven wrapper and provides an easy facade for you to remember commands and their use. This is the file, which you can run as such:

cd cas-overlay-template
./ help
Usage: [copy|clean|package|run|debug|bootrun]

What do these commands do?

Type Description
copy Copies the configuration from the local etc/cas/config directory to /etc/cas/config. See this guide to learn more.
clean Deletes any previously-built and leftover artifacts from the target directory.
package Runs clean and copy. Then packages the CAS web application artifact and run through the overlay to inject local customizations. The outcome is a target/cas.war file which is ready to be deployed.
run Involves package and then deploys and runs the CAS web application via its own embedded server container.
debug Same thing as run, except that you can remote-debug the CAS web application over port 5000.
bootrun Same thing as run, except the deployment is managed by the Spring Boot Maven plugin. This command has very specialized and limited use cases. Please review this issue to learn more.
Docs grow old. Always consult the overlay project's README file to keep to date.

As an example, here’s what I see if I were to run the package command:

./ copy package

Creating configuration directory under /etc/cas
Copying configuration files from etc/cas to /etc/cas/config
etc/cas/config/application.yml -> /etc/cas/config/application.yml
etc/cas/config/ -> /etc/cas/config/
etc/cas/config/log4j2.xml -> /etc/cas/config/log4j2.xml

[INFO] Scanning for projects...
[INFO] Using the MultiThreadedBuilder implementation with a thread count of 5
[INFO] ------------------------------------------------------------------------
[INFO] Building cas-overlay 1.0
[INFO] ------------------------------------------------------------------------
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cas-overlay ---
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ cas-overlay ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /cas-overlay-template/src/main/resources
[INFO] --- maven-compiler-plugin:3.3:compile (default-compile) @ cas-overlay ---
[INFO] No sources to compile
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ cas-overlay ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /cas-overlay-template/src/test/resources
[INFO] --- maven-compiler-plugin:3.3:testCompile (default-testCompile) @ cas-overlay ---
[INFO] No sources to compile
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ cas-overlay ---
[INFO] No tests to run.
[INFO] --- maven-war-plugin:2.6:war (default-war) @ cas-overlay ---
[INFO] Packaging webapp
[INFO] Assembling webapp [cas-overlay] in [/cas-overlay-template/target/cas]
[info] Copying manifest...
[INFO] Processing war project
[INFO] Processing overlay [ id org.apereo.cas:cas-server-webapp-tomcat]
[INFO] Webapp assembled in [786 msecs]
[INFO] Building war: /cas-overlay-template/target/cas.war
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------

You can see that the build attempts to download, clean, compile and package all artifacts, and finally, it produces a /cas-overlay-template/target/cas.war which you can then use for actual deployments.

You are allowed to pass any of Maven's native command-line arguments to the file. Things like -U or -X might be useful to have handy.


I am going to skip over the configuration of /etc/cas/config and all that it deals with. If you need the reference, you may always use this guide to study various aspects of CAS configuration.

Suffice it to say that, quite simply, CAS deployment expects the main configuration file to be found under /etc/cas/config/ This is a key-value store that is able to dictate and alter the behavior of the running CAS software.

As an example, you might encouter something like:

…which at a minimum, identifies the CAS server’s URL and prefix and instructs the running server to locate the logging configuration at file:/etc/cas/config/log4j2.xml. The overlay by default ships with a log4j2.xml that you can use to customize logging locations, levels, etc. Note that the presence of all that is contained inside /etc/cas/config/ is optional. CAS will continue to fall back onto defaults if the directory and the files within are not found.

Keep Track

It is VERY IMPORTANT that you contain and commit the entire overlay directory (save the obvious exclusions such as the target directory) into some sort of source control system, such as git. Treat your deployment just like any other project with tags, releases, and functional baselines.

Registering Applications

Client applications that wish to use the CAS server for authentication must be registered with the server apriori. CAS provides a number of facilities to keep track of the registration records and you may choose any that fits your needs best. In more technical terms, CAS deals with service management using two specific components: Individual implementations that support a form of a database are referred to as Service Registry components and they are many. There is also a parent component that sits on top of the configured service registry as more of an orchestrator that provides a generic facade and entry point for the rest of CAS without entangling all other operations and subsystems with the specifics and particulars of a storage technology.

In this tutorial, we are going to try to configure CAS with the LDAP service regitry.


First, ensure you have declared the appropriate module/intention in the build:


Next, you must teach CAS how to contact the LDAP server to read and write registration records. This is done in the file:


cas.serviceRegistry.ldap.ldapUrl=ldaps:// ldaps://
cas.serviceRegistry.ldap.bindDn=cn=Directory Manager,dc=example,dc=org
LDAP Schema
Service definitions are by default stored inside the description attribute as JSON objects with the objectClass casRegisteredService. The numeric identifier for each service definition that is used for lookups and search operations is also kept under attribute uid all of which you can of course customize. The format and syntax of the JSON is identical to that of JSON Service Registry. That’s all, as far as the schema goes.

That’s all. Next, you will need to pre-populate the LDAP server with registration records manually, or better yet, use the CAS Management web application’s user interface to do so in more interactive terms.

To populate the LDAP server manually, remember that there is no pre-defined fancy schema where a registration record in CAS would be broken apart and mapped to individual attributes one by one. The body of the registration record, sampled below, is stored in LDAP under the designated attribute:

  "@class" : "",
  "serviceId" : "",
  "name" : "ApplicationName",
  "id" : 1001,
  "evaluationOrder" : 10


A robust CAS deployment requires the presence and configuration of an internal database that is responsible for keeping track of tickets issued by CAS. CAS itself comes by default with a memory-based node-specific cache that is often more than sufficient for smaller deployments or certain variations of a clustered deployment. Just like the service management facility, large variety of databases and storage options are supposed by CAS under the facade of a Ticket Registry.

In this tutorial, we are going to configure CAS to use a Hazelcast Ticket Registry with the assumption that our deployment is going to be deployed in an AWS-sponsored environment. Hazelcast Ticket Registry is often a decent choice when deploying CAS in a cluster and can take advantage of AWS’s native support for Hazelcast in order to read node metadata properly and locate other CAS nodes in the same cluster in order to present a common, global and shared ticket registry. This is an ideal choice that requires very little manual work and/or troubleshoot, comparing to using options such as Multicast or manually noting down the address and location of each CAS server in the cluster.


First, ensure you have declared the appropriate module/intention in the build:


Next, the AWS-specific configuration of Hazelcast would go into our


That should do it.

Of course, if you are working on a more modest CAS deployment in an environment that is more or less owned by you and you prefer more explicit control over CAS node registrations in your cluster, the following settings would be more ideal:

# cas.ticket.registry.hazelcast.cluster.instanceName=localhost
# cas.ticket.registry.hazelcast.cluster.port=5701
# cas.ticket.registry.hazelcast.cluster.portAutoIncrement=true

Overlay Customization

If I cd into the target/cas directory, I can see an exploded version of the cas.war file. This is the directory that contains the results of the overlay process. Since I have not actually customized and overlaid anything yet, all configuration files simply match their default and are packaged as such. So as an example, let’s change something.

Digging further down, I notice there exists a /target/cas/WEB-INF/classes/ file, which is the default message bundle. I decided that I am going to change the text associated with screen.welcome.instructions.

Do NOT ever make changes in the target directory. The changesets will be cleaned out and set back to defaults every time you do a build. Follow the overlay process to avoid surprises.

First, I will need to move the file to my project directory so that Apache Maven during the overlay process can use that instead of what is provided by default.

Here we go:

cd cas-overlay-template
mkdir -p src/main/resources
cp target/cas/WEB-INF/classes/ src/main/resources/

Then I’ll leave everything in that file alone, except the line I want to change.

screen.welcome.instructions=Speak Friend and you shall enter.

Then I’ll package things up as usual.

./ package

[INFO] --- maven-war-plugin:2.6:war (default-war) @ cas-overlay ---
[INFO] Packaging webapp
[INFO] Assembling webapp [cas-overlay] in [/cas-overlay-template/target/cas]
[info] Copying manifest...
[INFO] Processing war project
[INFO] Processing overlay [ id org.apereo.cas:cas-server-webapp-tomcat]
[INFO] Webapp assembled in [1005 msecs]
[INFO] Building war: /cas-overlay-template/target/cas.war
[INFO] ------------------------------------------------------------------------

If I look at target/cas/WEB-INF/classes/ after the build, I should see that the overlay process has picked and overlaid onto the default my version of the file.

Only overlay and modify files you actually need and try to use externalized resources and configuration as much as possible. Just because you CAN override something in the default package, it doesn't mean that you should.


You have a number of options when it comes to deploying the final cas.war file. This post should help.

What About…?

For more content, please see this link.


It’s important that you start off simple and make changes one step at a time. Once you have a functional environment, you can gradually and slowly add customizations to move files around.

I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please feel free to engage and contribute as best as you can.

Misagh Moayyed

Related Posts

CAS 6.1.0 RC5 Feature Release which I present an overview of CAS 6.1.0 RC5 release.

Apereo CAS - Passwordless Authentication

Learn how to modify Apereo CAS to allow users to login without the need to remember a password.

Apereo CAS - Handling Authentication Webflow Errors with Grace

Learn how to modify Apereo CAS to customize exception handling and produce localized error messages for your deployment.

Apereo CAS - Are We Logged In Yet?

Learn how to modify and extend a CAS deployment to determine whether an SSO session is still valid and tied to a user authentication session.

Apereo CAS - REST API Integrations

Learn how to integrate with CAS using its REST API to authenticate, exchange tickets and get access to user profiles and attributes.

CAS 6.1.0 RC4 Feature Release which I present an overview of CAS 6.1.0 RC4 release.

Apereo CAS - Multifactor Provider Selection

Learn how to configure CAS to integrate with and use multiple multifactor providers at the same time. This post also reveals a few super secret and yet open-source strategies one may use to select appropriate providers for authentication attempts, whether automatically or based on a menu.

Apereo CAS - Dockerized Hazelcast Deployments

Learn how to run CAS backed by a Hazelcast cluster in Docker containers and take advantage of the Hazelcast management center to monitor and observer cluster members.

Apereo CAS - Configuration Security w/ Jasypt

Learn how to secure CAS configuration settings and properties with Jasypt.

CAS 6.1.0 RC3 Feature Release which I present an overview of CAS 6.1.0 RC3 release.