APEREO CASDocumentation

Enterprise Authentication for All Earthlings and Beyond

Identity, Single Sign-On and Access Management
View on GitHub

Reloading Changes

The CAS spring cloud configuration server is able to consume properties and settings via the profiles outlined here. The server is constantly monitoring changes to the underlying property sources automatically, but has no way to broadcast those changes to its own clients, such as the CAS server itself, which would act as a client of the configuration server expecting change notifications to quietly reload its configuration.

Therefore, in order to broadcast such change events CAS presents various endpoints that allow the adopter to refresh the configuration as needed. This means that an adopter would change a required CAS settings and then would submit a request to CAS to refresh its current state. All CAS internal components that are affected by the external change are quietly reloaded and the setting takes immediate effect, completely removing the need for container restarts or CAS re-deployments.

:information_source: Do Not Discriminate!

Most if not all CAS settings are eligible candidates for reloads. CAS should be smart enough to reload the appropriate configuration, regardless of setting/module that ends up using that setting. All is fair game, as the entire CAS web application inclusive of all modules and all relevant settings may be completely and utterly reloadable. If you find an instance where this statement does not hold, please speak up.

Reload Strategy

CAS uses Spring Cloud to manage the internal state of the configuration. The configuration server that is provided by Spring Cloud embedded in CAS is constantly monitoring sources that house CAS settings and upon changes will auto-refresh itself.

The CAS application context and runtime environment that contains all Spring components and bean definitions can be reloaded using the following administrative endpoints:

features
Third-party endpoint1 operationNot exposed by default
refresh
Third-party endpoint1 operationNot exposed by default
busenv
Third-party endpoint2 operationsNot exposed by default
busrefresh
Third-party endpoint2 operationsNot exposed by default
serviceregistry
Third-party endpoint2 operationsNot exposed by default
1

Turn the endpoints on and expose them over the web. One entry covers every operation. By default only info, health and status are exposed.



1
2
3
4
5
6
7
8



management.endpoint.features.access=UNRESTRICTED
management.endpoint.refresh.access=UNRESTRICTED
management.endpoint.busenv.access=UNRESTRICTED
management.endpoint.butshotdown.access=UNRESTRICTED
management.endpoint.bus-refresh.access=UNRESTRICTED
management.endpoint.busrefresh.access=UNRESTRICTED
management.endpoint.serviceregistry.access=UNRESTRICTED
management.endpoints.web.exposure.include=features,refresh,busenv,butshotdown,bus-refresh,busrefresh,serviceregistry

Endpoints may be mapped to other paths. For example, to serve health at healthcheck:



1



management.endpoints.web.path-mapping.health=healthcheck

In the event that the standalone configuration profile is used to control and direct settings and Spring Cloud configuration server is disabled, CAS may begin to automatically watch and monitor the configuration files indicated by the profile and will auto-reload the state of the runtime application context automatically.

Support is enabled by including the following dependency in the WAR overlay:



1
2
3
4
5



<dependency>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-core-events-configuration</artifactId>
    <version>${cas.version}</version>
</dependency>





1



implementation "org.apereo.cas:cas-server-core-events-configuration:${project.'cas.version'}"





1
2
3
4
5
6
7
8
9



dependencyManagement {
    imports {
        mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
    }
}

dependencies {
    implementation "org.apereo.cas:cas-server-core-events-configuration"
}





1
2
3
4
5
6
7
8
9
10



dependencies {
    /*
        The following platform references are included automatically and are listed for reference only.

        implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")
        implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
        
    */
    implementation "org.apereo.cas:cas-server-core-events-configuration"
}

Spring application context will fail to refresh beans that are excluded (or conditionally activated/created) at initialization/startup time, because there is nothing to refresh to begin with. Refresh requests and beans marked with @RefreshScope only work in scenarios where there is an existing reference to a bean in the application context hierarchy that can be refreshed; beans or configuration classes that are skipped during the startup and application context initialization will never be refreshable, because they are not re-created upon refresh requests. In other words, refresh requests only work best when there is a setting or property whose existing value changes from A to B; if there was no A to begin with, or if A is being removed, refresh requests and the reload strategy may fall short.

Actuator Endpoints

The following endpoints are provided by CAS:

health
Third-party endpoint2 operationsExposed by default
1

Turn the endpoint on and expose it over the web. One entry covers every operation. By default only info, health and status are exposed.



1
2



management.endpoint.health.access=UNRESTRICTED
management.endpoints.web.exposure.include=health

Endpoints may be mapped to other paths. For example, to serve health at healthcheck:



1



management.endpoints.web.path-mapping.health=healthcheck