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.1.0 RC5 Feature Release

...in 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

...in 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

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