Apereo CAS - Slurp Configuration with Groovy


Collaborate
The blog is managed and hosted on GitHub. If you wish to update the contents of this post or if you have found an inaccuracy and wish to make corrections, we recommend that you please submit a pull request to this repository.

CAS allows you to externalize your configuration settings so you can work with the same CAS instance in different environments. You can use properties files, YAML files, environment variables and command-line arguments (just to name a few!) to externalize and provide configuration. These strategies present a very flexible and powerful way to manage CAS configuration for production deployments in a variety of use cases.

As your CAS deployment moves through the deployment pipeline from dev to test and into production, you can manage the configuration between those environments separately, and be certain that each tier has everything it needs to run when the server migrates. Tier-specific configuration is usually managed and activated through the use of application (aka. Spring) profiles while the rest of the more common settings are gathered centrally that apply to all environments. When you run CAS in standalone mode specially, the default configuration directory on the filesystem (i.e. /etc/cas/config) may include (cas|application).(yaml|yml|properties) files that can be used to control behavior. Such configuration files may also specifically apply to a profile (i.e. ldap.properties) that can be activated using spring.profiles.active or spring.profiles.include settings.

Starting with CAS 6, Groovy can also serve as a strategy for loading configuration in a way that allows one to consolidate common and tier-specific files in one place. This tutorial explores that possibility with a starting position is based on the following:

  • CAS 6.0.0-RC4
  • Java 11
  • CAS Overlay (The master branch specifically)

Groovy ConfigSlurper

If you are familiar with Groovy, then ConfigSlurper is no stranger to you. This is a utility class for reading configuration files defined in the form of Groovy scripts. Configuration settings can be defined using dot notation or scoped using closures:

 grails.webflow.stateless = true
 smtp {
     mail.host = 'smtp.myisp.com'
     mail.auth.user = 'server'
 }
 resources.URL = "http://localhost:80/resources"

CAS takes advantage of this very component, allowing you to isolate tier-specific settings in form of conditional closures. In the simplest scenario, it expects to find a cas.groovy file in the same configuration directory while running standalone mode that might look like this:

profiles {
    dev {
        cas.authn.accept.users="test::dev"
    }
    prod {
        cas.authn.accept.users="test::prod"
    }
}

cas.common.setting="value"

When you run CAS using the dev profile, the collection of settings that are picked up from the script are:

cas.authn.accept.users="test::dev"
cas.common.setting="value"

…and when you run CAS using the prod profile, the collection of settings that are picked up from the script are:

cas.authn.accept.users="test::prod"
cas.common.setting="value"

For small configuration changes between tiers, this is arguably simpler than having, for example, cas.properties, dev.properties and prod.properties files. For anything else larger and more complicated, you still may want to think about separating settings into multiple files or perhaps consider using the Spring Cloud Config Server.

Finale

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 RC3 Feature Release

...in which I present an overview of CAS 6.1.0 RC3 release.

Apereo CAS 6.1.x - Credential Caching & Proxy AuthN

Learn how you may configure Apereo CAS to capture and cache the credential's password and the proxy-granting ticket in proxy authentication scenarios, pass them along to applications as regular attributes/claims. We will also be reviewing a handful of attribute release strategies that specifically affect authentication attributes, conveying metadata about the authentication event itself.

Apereo CAS 6.1.x - Attribute Repositories w/ Person Directory

An overview of CAS attribute repositories and strategies on how to fetch attributes from a variety of sources in addition to the authentication source, merge and combine attributes from said sources to ultimately release them to applications with a fair bit of caching.

Apereo CAS 6.1.x - Building CAS Feature Modules

An overview of how various CAS features modules today can be changed and tested from the perspective of a CAS contributor working on the codebase itself to handle a feature request, bug fix, etc.

CAS 6.1.0 RC2 Feature Release

...in which I present an overview of CAS 6.1.0 RC2 release.

Apereo CAS - Riffing on Attribute Release Policies

Learn how to release the kraken of attributes to CAS clients, relying parties and service providers using a variety of attribute release policies and authentication protocols, sampled and collected here to fun and profit.

Apereo CAS - Delegated Authentication to SAML2 Identity Providers

Learn how your Apereo CAS deployment may be configured to delegate authentication to an external SAML2 identity provider.

Apereo CAS - Custom Login Fields w/ Dynamic Bindings

Learn how to extend the Spring Webflow model to add custom fields to the CAS login form and the authentication process and take advantage of the additional user-provided data in customized authentication handlers.

Apereo CAS as an OAuth2 Authorization Server

Learn how to configure CAS as an OAuth2 Authorization Server and configure Spring Boot client app to work with it

Apereo CAS - SAML2 Identity Provider Integration w/ Gitlab (also staring HAProxy and LDAP)

Learn how Apereo CAS may act as a SAML2 identity provider for Gitlab and run everything locally on a workstation with Docker and Java.