CAS 5 - Maintaining Protocol Compatibility


Collaborate
The 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.

The third specification of the CAS protocol was released around the time CAS v4.0.0 came into existence. The primary objective of the revision was to bring the spec up to speed with common community practices and extensions, one of which most significantly was the ability to let CAS release attributes to authorized relying parties and applications.

In order to preserve protocol backward-compatibility, a new /p3/serviceVaildate endpoint was added whose only job was to release attributes to be consumed by clients. This way, existing CAS clients unable to parse the new <cas:attributes> block in the validation response could continue to function as they did. Newer clients could simply hit the new endpoint to receive attributes.

Problem Statement

There are cases where a certain number of today’s CAS clients are perfectly able to consume attributes from CAS protocol v2. How? Because support for attributes was an accepted mod made by most deployers and client developers. A deployer running some version of CAS 3.x for instance had already applied the change to CAS for attribute release and had built clients or instructed vendors to build clients such that they all could consume attributes and enjoy coolness.

How’s that situation convered in the most recent CAS 5 release line?

Solution

The trick is to ensure that the component responsible for validating tickets and producing the final payload is using the correct versions of the view/response which match that of CAS protocol v3. The most bullet-proof way of applying this change is with CAS 5’s auto-configuration strategy described below.

CAS 5.0.x

Design your own @Configuration class and have it simply match the following body. This component will be placed inside the CAS overlay under /src/main/java/org/apereo/cas/config and it must be housed inside the Java package org.apereo.cas. You may need to create the directory structure and you may also need to ensure relevant dependencies are under the compile scope so the configuration below can properly compile.

As you can see below, all we are doing is swapping out one set of views with another.

package org.apereo.cas.config;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.View;
import org.apereo.cas.web.ServiceValidateController;

import javax.annotation.PostConstruct;

/**
 * This is {@link CustomConfiguration} that replaces the CAS Protocol 2 validation endpoint (/serviceValidate)
 * with the CAS Protocol 3 (essentially applying the attribute modification to CAS protocol 2..
 *
 * @author John Gasper
 * @since 5.0.x
 */

@Configuration("CustomConfiguration")
public class CustomConfiguration
{
    private static final Logger LOGGER = LoggerFactory.getLogger(CustomConfiguration.class);

    @Autowired
    @Qualifier("serviceValidateController")
    ServiceValidateController serviceValidateController;

    @Autowired
    @Qualifier("cas3ServiceSuccessView")
    View cas3ServiceSuccessView;

    @Autowired
    @Qualifier("cas3ServiceFailureView")
    View cas3ServiceFailureView;

    @PostConstruct
    protected void initializeRootApplicationContext() {
        serviceValidateController.setSuccessView(cas3ServiceSuccessView);
        serviceValidateController.setFailureView(cas3ServiceFailureView);
    }
}

CAS 5.1.x

Same exact strategy as 5.0.x, except that now you’re given the freedom to put the Java component anywhere inside any package in the overlay project, provided it’s correctly registered with the CAS auto configuration engine.

CAS 5.2.x, 5.3.x

All that is still way too much work, right? So starting with CAS 5.2.x all one should have to do is to introduce the following setting in the cas.properties:

cas.view.cas2.v3ForwardCompatible=true

That’s it.

So…

Special thanks to @jtgasper3 for sharing this neat trick and letting me brag about it.

Misagh Moayyed

Related Posts

CAS 6.1.0 RC5 Feature Release

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

Apereo CAS - Are We Logged In Yet?

Learn how to modify and extend a CAS deployment to determine whether an SSO session is still valid and tied to a user authentication session.

Apereo CAS - REST API Integrations

Learn how to integrate with CAS using its REST API to authenticate, exchange tickets and get access to user profiles and attributes.

CAS 6.1.0 RC4 Feature Release

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

Apereo CAS - Multifactor Provider Selection

Learn how to configure CAS to integrate with and use multiple multifactor providers at the same time. This post also reveals a few super secret and yet open-source strategies one may use to select appropriate providers for authentication attempts, whether automatically or based on a menu.

Apereo CAS - Dockerized Hazelcast Deployments

Learn how to run CAS backed by a Hazelcast cluster in Docker containers and take advantage of the Hazelcast management center to monitor and observer cluster members.

Apereo CAS - Configuration Security w/ Jasypt

Learn how to secure CAS configuration settings and properties with Jasypt.

CAS 6.1.0 RC3 Feature Release

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

Apereo CAS - Webflow Decorations

Learn how you may decorate the Apereo CAS login webflow to inject data pieces and objects into the processing engine for display purposes, peace on earth and prosperity of all mankind, etc. Mainly, etc.

Apereo CAS - SAML2 Metadata Query Protocol

Learn how you may configure Apereo CAS to fetch and validate SAML2 metadata for service providers from InCommon's MDQ server using the metadata query protocol.