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

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

CAS 6.1.x Deployment - WAR Overlays

Learn how to configure and build your own CAS deployment via the WAR overlay method, get rich quickly, stay healthy indefinitely and respect family and friends in a few very easy steps.

Apereo CAS - Have you been pawned?

Learn how Apereo CAS may be configured to check for pawned passwords and warn the user, using the haveibeenpawned.com service

Apereo CAS - OohLala Mobile SAML2 Integration

Learn how to integrate OohLala Mobile with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - Cranium Cafe SAML2 Integration

Learn how to integrate Cranium Cafe with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - eLumen SAML2 Integration

Learn how to integrate eLumen with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - Rave SAML2 Integration

Learn how to integrate Rave with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - HireTouch SAML2 Integration

Learn how to integrate HireTouch with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - Microsoft Office 365 SAML2 Integration

Learn how to integrate Microsoft Office 365 with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - HappyFox SAML2 Integration

Learn how to integrate HappyFox with Apereo CAS running as a SAML2 identity provider.