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:
6.1.x
11
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.
To do so, you should start by designing your own configuration component to include the following bean:
@Bean
public ServiceMatchingStrategy serviceMatchingStrategy() {
return new MyServiceMatchingStrategy(...);
}
The general outline of MyServiceMatchingStrategy
should have to follow the below example:
public class MyServiceMatchingStrategy implements ServiceMatchingStrategy {
@Override
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,
Monday-Friday
9am-6pm, Central European Time
7am-1pm, U.S. Eastern Time
Monday-Friday
9am-6pm, Central European Time