Apereo CAS - Service Matching Strategies

Posted by Misagh Moayyed on October 28, 2019 · 3 mins read ·
This blog post was originally posted on Apereo GitHub Blog.


Per the CAS Protocol, validating service tickets requires a service parameter that is expected to be the identifier of the service for which the service ticket was issued. In other words, CAS requires and enforces an exact match between the given service identifier and one that was supplied originally for ticket creation.

In this short tutorial, we are briefly going to review the specifics of this matching strategy and ways that it might be customized. Our starting position is based on:


The default service matching strategy is exact and enforced by DefaultServiceMatchingStrategy. The strategy can be replaced if, for example, you wanted to disregard query string parameters and extract service identifiers solely by their URL.

Altering the internal mechanics of a CAS server may lead to a problematic insecure configuration and may also jeopradize the population of giant pandas. Such customizations should only be applied if absolutely necessary when all other alternatives are considered and ruled out.

To do so, you should start by designing your own configuration component to include the following bean:

public ServiceMatchingStrategy serviceMatchingStrategy() {
    return new MyServiceMatchingStrategy(...);

The general outline of MyServiceMatchingStrategy should have to follow the below example:

public class MyServiceMatchingStrategy implements ServiceMatchingStrategy {
    public boolean matches(final Service service, final Service serviceToMatch) {
        service - the original service supplied when the ticket was created.
        serviceToMatch - the provided service requesting the ticket to be validated.

        Figure out what needs to be done and return either true or false.
        return ...;

That’s all.


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.

Finally, if you benefit from Apereo CAS as free and open-source software, we invite you to join the Apereo Foundation and financially support the project at a capacity that best suits your deployment. If you consider your CAS deployment to be a critical part of the identity and access management ecosystem and care about its long-term success and sustainability, this is a viable option to consider.

Happy Coding,

Misagh Moayyed