Overview

Per the CAS Protocol, service tickets issued by a CAS server are expected to be returned to the original service identifier provided in the initial authentication request via the service parameter. While this default behavior is enforced by the Apereo CAS server, there may be situations where the ultimate redirection URL may need to be customized or altered for advanced integrations.

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

• CAS 6.2.x
• Java 11
• CAS WAR Overlay

A similar blog post on how tuning service matching strategies can be found here.

Configuration

The default redirection strategy is exact and enforced by WebApplicationServiceResponseBuilder, whose job is to build an appropriate response to the authentication request. The builder supports normal authentication requests from generic web applications and is capable of producing responses as a GET, POST, etc. The definition of the builder can of course be customized and replaced since it’s defined as a Spring bean in the running application context.

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

@Bean
public ResponseBuilder<WebApplicationService> webApplicationServiceResponseBuilder() {
    return new MyWebApplicationServiceResponseBuilder(...);
}

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

public class MyWebApplicationServiceResponseBuilder 
        extends WebApplicationServiceResponseBuilder {
    
    @Override
    protected String determineServiceResponseUrl(WebApplicationService service) { 
        if (shouldWeCustomizeRedirectionUrls(service)) {
            return ...;
        }
        return super.determineServiceResponseUrl(service);
    }
}

Your task would then be to implement the determineServiceResponseUrl() method to provide your own custom logic.

Alternatively, you can specify an override for the registered service definition:

{
  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "testId",
  "name" : "TEST",
  "id" : 1,
  "redirectUrl" : "https://somewhere.example.org",
  "evaluationOrder" : 1
}

So…

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