Apereo CAS - Managing Services via Git

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.


Applications that are integrated with the Apereo CAS server typically are registered with the system as JSON or YAML files. Such files can be stored in a remote git repository to take advantage of all native operations and benefits of distributed source control such as version tracking, history, etc, given they are considered source code after all.

Using a git-backed service registry, CAS is given the ability to pull down and clone a repository and watch for changes at defined intervals. In this tutorial, we are going to quickly review the steps required to manage application records via Git.

Our starting position is based on:


Once you have prepped your CAS overlay with the correct auto-configuration module, you will need to instruct CAS to try and connect to the repository:



I am using a public repository on Github whose master branch. If you are working with a private git repository that requires credentials for access, you can specify those as well:

# cas.serviceRegistry.git.username=
# cas.serviceRegistry.git.password=

My current contains the following two files. One is a Test-1.json file at the root of the repository with the following content:

  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "testId",
  "name" : "TEST",
  "id" : 1,
  "evaluationOrder" : 1

…and the other is a SAMPLE-2.yaml inside a test folder:

--- !<org.apereo.cas.services.RegexRegisteredService>
serviceId: "testId-yaml"
name: "SAMPLE"
id: 2
description: "description"
attributeReleasePolicy: !<org.apereo.cas.services.ReturnAllAttributeReleasePolicy> {}
accessStrategy: !<org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy>
  enabled: true
  ssoEnabled: true

We expect that CAS would connect to the repository’s master branch to pull down the above files regardless of where they are physically located in the repository directory structure.

To make it easier to test the changes, I am also going to include the auto-configuration module for reporting in the CAS overlay to take advantage of registeredServices actuator endpoint. With the inclusion of this module, I can instruct CAS to enable it and allow anonymous requests for easy testing:



At this point, we should be ready to test.


Once you build and bring up the deployment, the following should be apparent in the CAS DEBUG logs:

<[Pull] -> [1], total [2] [50]% Completed>
<[Pull] -> [2], total [2] [100]% Completed>
<Finished [Pull] -> [2], total [2] [100]% Completed>
<Successfully pulled changes from the remote repository>
<Adding registered service [testId-yaml] with name [SAMPLE] and internal identifier [2]>
<Adding registered service [testId] with name [TEST] and internal identifier [1]>
<Loaded [2] service(s) from [GitServiceRegistry].>
<Service registry [GitServiceRegistry] contains [2] service definitions>

Note that since CAS is by default configured to periodically reload the contents of the service registry, from time to time based on the pre-defined interval, the following log messages should appear:

Loaded [2] service(s) from [GitServiceRegistry].

…which means we can go to the repository and make a change to the description field of our YAML service file:

--- !<org.apereo.cas.services.RegexRegisteredService>
serviceId: "testId-yaml"
name: "SAMPLE"
id: 2
description: "Description is updated to be more interesting"
attributeReleasePolicy: !<org.apereo.cas.services.ReturnAllAttributeReleasePolicy> {}
accessStrategy: !<org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy>
  enabled: true
  ssoEnabled: true

…and CAS should be able to pull down the change and reload the corresponding service file. To observe that change is activated, we can submit a request to CAS and ask for our service:

curl https://sso.example.org/cas/actuator/registeredServices/2 | jq

By default, the response type is always in JSON. If you prefer YAML, by all means:

curl  -H "Accept: application/vnd.cas.services+yaml" https://sso.example.org/cas/actuator/registeredServices/2

Of if you wish to force-reload the contents of the service registry:

curl https://sso.example.org/cas/actuator/registeredServices


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 know that all other use cases, scenarios, features, and theories certainly are possible as well. Feel free to engage and contribute as best as you can.

Happy Coding,

Misagh Moayyed

Related Posts

CAS 6.2.0 RC1 Feature Release

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

Apereo CAS - Simple Multifactor Authentication

Learn to configure Apereo CAS to act as a simple multifactor provider itself.

Apereo CAS 2019 Survey Results

...in which I present a summarized view of the latest CAS community survey.

CAS 6.1.0 RC6 Feature Release

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

Apereo CAS - Ticket Distribution with JMS

Learn to configure Apereo CAS to JMS and messages queues to broadcast tickets and tokens across a deployment cluster.

CAS Vulnerability Disclosure

Disclosure of a security issue with the CAS software.

Apereo CAS - SMS Notifications via Twilio

Learn to configure Apereo CAS for SMS notifications via Twilio.

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.