Apereo CAS - Configuration Management with Azure Key Vault

Posted by Misagh Moayyed on April 10, 2023 · 6 mins read ·
Content Unavailable
Your browser is blocking content on this website. Please check your browser settings and try again.

Azure Key Vault provides secure storage of generic secrets, such as passwords and database connection strings. Apereo CAS deployments can integrate with Azure Key Vault as a regular property source to read secrets and properties before CAS starts.

This tutorial specifically requires and focuses on:


Once you have prepared your CAS build with the appropriate extension module, you will need to place the following properties inside a bootstrap.properties or bootstrap.yaml file:

          property-source-enabled: true
            - name: CasConfiguration
              endpoint: https://my.vault.azure.net
                client-secret: ...
                client-id: ...
                tenant-id: ...
                subscription-id: ...

In the same section, you can also control some advanced settings such as retry options and connection timeouts:

          property-source-enabled: true
            - name: CasConfiguration
                  delay: PT1S
                  max-retries: 5
                mode: FIXED
                response-timeout: PT2S
                write-timeout: PT2S
                connect-timeout: PT2S
                read-timeout: PT2S

That should be it. Now, you can begin configuring your Azure Key Vault instance with CAS secrets:


Troubleshooting configuration and runtime issues can be especially tricky. Due to the way Spring Cloud property sources load during the very initial bootstrapping phase, connection or configuration problems often tend to be invisible, not logged, and cause the application to crash without any clues. You may need to stand up a debugger and trace the application execution to determine the root cause.

The following problems are however easy to diagnose and solve:

Invalid Client Secret

You might run into the following error:

AADSTS7000215: Invalid client secret provided. Ensure the secret being sent in the request 
is the client secret value, not the client secret ID, for a secret added to app '...'.

This is a configuration mistake and has to do with the fact that the client-secret does not point to a secret, but to a secret identifier. You need to make sure the correct secret value is defined:

Access Denied

You might run into the following error:

The user, group or application '...' does not have secrets list permission on key vault '...'

This error indicates that the account used to authenticate into Azure Key Vault does not have the necessary permissions to interact with the service and list/read secrets. To remedy this, you need to ensure the service account or credential that is used to connect to Azure Key Vault has the right permissions and is assigned the correct access policy:

Need Help?

If you have questions about the contents and the topic of this blog post, or if you need additional guidance and support, feel free to send us a note and ask about consulting and support services.


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