Interrupt CAS With Class

Posted by Misagh Moayyed on August 30, 2017 · 4 mins read ·
Content Unavailable
Your browser is blocking content on this website. Please check your browser settings and try again.
This blog post was originally posted on Apereo GitHub Blog.

The fastest route to a 10X engineer is to give them 0.1X the distractions. - Eric Meyer

While that is generally sensible advice, when it comes to CAS there are times where you wish to interrupt the CAS authentication flow and the present the end-user with notifications and announcements. A common use case deals with presenting a message board during the authentication flow to select users and then optionally require the audience to complete a certain task before CAS is able to honor the authentication request and establish a session. Examples of such messages tasks may include: “The kitchen’s menu today features Khash. Click here to get directions.” or “The office of compliance and regulations has announced a new policy on using forks. Click to accept, or forever be doomed with spoons”.

This is a tutorial on how to present such interruptions to your CAS audience, as a fairly recent feature in CAS 5.2.x and beyond. To learn more about this behavior, please see this guide.

As of this writing, CAS 5.2.x is not officially released. See the release schedule for more info.

Interrupt Source

First and foremost, there needs to be an engine of some sort that is able to produce notifications and interruptions. CAS supports a range of such engines that are backed by JSON & Groovy resources, REST endpoints or one you decide to create and inject into the runtime.

For the purposes of this tutorial, I will be using the static JSON resource which is a perfectly suitable option for super small deployments or relevant during development and testing. The JSON resource path is taught to CAS via the following setting:


Interrupt Rules

Once you have defined the above setting and assuming your overlay is prepped with relevant configuration module, CAS will attempt to understand the interruption rules that are defined in the interrupt.json file. My rules are defined as such:

  "casuser" : {
    "message" : "We have interrupted your CAS authentication workflow to bring you the following information. Select one of the links below to go somewhere and do something fun and then come back to continue with <strong>CAS</strong>.",
    "links" : {
      "Go to Google" : "",
      "Go to Yahoo" : ""
    "ssoEnabled" : false,
    "interrupt" : true,

The above ruleset simply says: Whenever casuser authenticates, present the message to the user with a number of links. Make sure an SSO session is not established which would have the user present credentials again in subsequent attempts.

The Looks

Once that is all in place, casuser will see the following screen, after having authenticated successfully:


It’s that simple.


For more advanced and production-quality interruptions you likely need to write a Groovy script or design a REST endpoint that ties CAS with your own institutional messages and you most certainly should want to decorate the user interface much better.

Given this is very new today, I am sure you will find plenty of opportunities to improve the functionality with more cowbell. Laundry doesn’t fold itself so please do.

Misagh Moayyed