Apereo CAS - Customized Settings


Collaborate
This 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.

Overview

Starting with version 5.3.x, CAS begins to own its own configuration namespace rather more seriously, rejecting any settings that are no longer supported or recognized. While this works quite well for configuration settings that tend to get deprecated and moved about from release to release, it also has a side-effect of not allowing any custom settings to be defined by the adopter. In practice, adding custom settings to a cas namespace is likely less than ideal, as it would be best to denote localized changes using their own specific namespaces and settings. So, in this tutorial, a short overview of extending CAS to use customized properties is presented as well as an alternative simplified strategy to introduce configuration options into the runtime without dabbling into much code.

Our starting position is based on the following:

Custom Properties: Take #1

This strategy more or less applies to any CAS 5.x deployment as more of a heavyweight approach most useful when you are about to extend the CAS configuration to alter its workings by overriding conditional beans or introducing new components and behavior into the runtime engine.

You will need to start by defining your collection of settings first:

@ConfigurationProperties(value = "custom")
public class CustomConfigurationProperties {
    private String settingName;

    public String getSettingName() {
        return settingName;
    }

    public void setSettingName(final String value) {
        this.settingName = value;
    }
}

Or, if you can afford a bit of syntactic sugar with Lombok:

@Getter
@Setter
@ConfigurationProperties(value = "custom")
public class CustomConfigurationProperties {
    private String settingName;
}

Next, you need to extend the CAS configuration to have your configuration settings be recognized by the runtime:

@Configuration("SomethingConfiguration")
@EnableConfigurationProperties(CustomConfigurationProperties.class)
public class SomethingConfiguration {

    @Autowired
    private CustomConfigurationProperties customProperties;
}

…and then, you should be able to define settings in your cas.properties file such as:

custom.settingName=some-value

…and have them be recognized by SomethingConfiguration in all of its inner beans that you shall design and build.

Of course, this is a fair amount of work to get something so seemingly simple done. Let’s try to simplify this a bit.

Custom Properties: Take #2

Starting with CAS 5.3.x, a new cas.custom.properties namespace is introduced that is able to own all arbitrary settings. An example for this new syntax would be:

cas.custom.properties.customPropertyName1=customPropertyValue1
cas.custom.properties.customPropertyName2=customPropertyValue2
cas.custom.properties.customPropertyName3=customPropertyValue3

…that is to say, you can substitute anything you prefer for the customized property name and values.

Additionally, all CAS-owned properties including the custom namespace of course are now accessible in CAS views and templates such that one is able to do:

<p th:text="${casProperties.custom.properties.customPropertyName1}" />

…or:

<p th:text="${casProperties.server.name`}" />

Of course, note that the above syntax only works for settings that are provided by CAS. If you need access anything that is provided by Spring Boot, such as server.port or anything that pretty much does not have the cas. prefix, then you need to fall back onto fancier strategies of working with Thymeleaf to access application beans and pull up those settings where needed. Needless to say, that likely is a futile endeavor.

So…

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.

Happy Coding,

Misagh Moayyed

Related Posts

CAS 6.0.0 RC1 Feature Release

...in which I present an overview of CAS 6.0.0 RC1 release.

Get Productive with Shell Aliases

A collection of useful shell aliases, gathered over the years to help increase one's productivity and developer happiness.

feat(conventional_commits): signal breaking changes in commit titles

In which I suggest Conventional Commits should be enhanced to reflect the breakingness of commits in their commit message titles.

uPortal annual report, June 2018 edition

Ecoysystem. Releases. Community. Fiscal responsibility.

One Can Only Hope in Buchistan

A true story inspired by real events. Seriously. Bryan Cranston has been approached for the role of "Some".

Apereo CAS - Extending Webflows

Learn and master extending CAS 5 Spring Webflow definitions.

Apereo CAS - Administrative Endpoints & Monitoring

Gain insight into your running Apereo CAS deployment in production. Learn how to monitor and manage the server by using HTTP endpoints and gather metrics to diagnose issues and improve performance.

Apereo CAS - Custom Authentication & Attribute Sources

Master writing custom authentication handlers/schemes in CAS and learn how to design custom data sources that can produce user claims and attributes.

Apereo CAS - User Interface Customizations

A short tutorial on Apereo CAS user interface customizations, including themes, localization and dynamic views for all those who enjoy front-end development and suffer from instant gratification.

CAS Multifactor Authentication with Google Authenticator

A short walkthrough to demonstrate how one might turn on multifactor authentication with CAS using Google Authenticator, leveraging a variety of triggers.