CAS 6.0.0 RC1 Feature Release

The official CAS 5.3.0 GA was released on June 29th, 2018. Since then, the project has been moving forward with development of the next feature release that is tagged as 6.0.0. Note that this is a major release of the CAS software which may present significant changes in architecture, configuration or behavior. Please review the release policy to learn more about the scope of the release.

This post intends to highlight some of the improvements and enhancements packed into the first release candidate in the 6.0.0 series.

Shake Well Before Use

We strongly recommend that you take advantage of the release candidates as they come out. Waiting for a GA release is only going to set you up for unpleasant surprises. A GA is simply a tag and nothing more. Note that CAS releases are strictly time-based releases; they are not scheduled or based on specific benchmarks, statistics or completion of features. To gain confidence in a particular release, it is strongly recommended that you start early by experimenting with release candidates and/or follow-up snapshots.

In order to start experimenting with release candidates, at any given time, you should be able to append -SNAPSHOT to the CAS version specified in order to take advantage of snapshot builds as changes are made and published.

Overlay

In the build.properties of the overlay, adjust the following setting:

casVersion=6.0.0-RC1

The template overlays are getting reorganized to some degree before they can be fully functional with CAS 6. Be sure to double check the branch and the overlay structure as you navigate though CAS versions and release candidates.

Changes

• New & Noteworthy
  • Java 10
  • Servlet Specification v4
  • Spring v5
  • Spring Boot v2
  • Metrics
  • Endpoints
    • Endpoint Security
  • CAS Command-line Shell
  • Dynamic SAML2 Metadata
  • Webflow Decorations
  • Adaptive Authentication IP Intelligence
  • Azure MFA Integration
  • Google Authenticator Account Management
  • OAuth & OpenID Connect JSON Output
  • OAuth Device Flow
  • OAuth Proof Key Code Exchange (PKCE)
  • CAS as Multifactor Authentication Provider
  • Couchbase Audits
  • SAML2 Metadata Health Status
  • OAuth Token Introspection
  • YubiKey Account Management
  • Nexmo SMS Integration
• Small Stuff
• Library Upgrades
• Resources
• Get Involved
• Credits

New & Noteworthy

Java 10

Oracle recently announced that they intend to move Java to a release every six months. Under the new release schedule, Oracle proposes strict time-based releases, known as feature releases. These will appear every year in March and September. The new release schedule is intended to begin immediately after the release of Java 9 (which is long-gone at this point), with the next release of Java to come in early 2018.

The release schedule of the CAS software quite happily lends itself to the Java release schedule as well. There has been a feature release once every 6 months or so for the past couple of years and such releases have exclusively been time-based releases with a number of candidates in between them for adopters to experiment. That being said, in order to keep up with the Java release schedule, stay on a supported platform and keep the progress ball moving forward, the minimum required Java version is set to be 11 starting with CAS 6.

This has not been an easy effort; the CAS 6 development has been in progress since February 2018 with early testing of snapshots and release candidates of Java as well as all other software packages and libraries to ensure a successful build and deployment model. For the most part, all functionality continues to remain the same as it was and the change in platform requirements should remain completely invisible to the deployment.

Note that this particular release candidate will be based on top of Java 10, having passed 9 already. As other libraries begin to catch up with Java 11 and provider better support, CAS will ultimately switch to Java 11 before the final GA release.

While there are no specific plans as of this writing, there will likely be follow-up feature releases after CAS 6 in form of 6.1, 6.2, etc each of which may require and depend on future Java releases such as 12, 13, etc.

Servlet Specification v4

The embedded server containers provided by CAS (Apache Tomcat, Jetty, etc) have been and will be upgraded to include support for the new specification version. This will most notably include required support for Apache Tomcat 9+ and Undertow 2+.

Spring v5

Given changes in the platform requirements, the Spring framework that is very heavily used internally by CAS has been updated to its most recent version that is version 5.0.x. You can read all about Spring 5 here.

While for the most part, the upgrade is rather invisible to the CAS developer and adopter, one area that is negatively impacted by the change is the SAML2 functionality in CAS that uses the Velocity templating engine needed by the OpenSAML library to submit SAML responses, etc. Velocity support is no longer available in Spring 5 and additional measures are taken in CAS to ensure OpenSAML and friends and continue to do the job without relying on Velocity support assumed to be available with the Spring framework.

It is quite likely that CAS would ultimately switch to Spring 5.1.x to take full advantage of Java 11 support.

Spring Boot v2

CAS is entirely based on the Spring Boot framework at heart, which controls the orchestration and management of CAS settings, configuration modules, and many other things. Moving to the newer version of the Java platform as well as the Spring framework requires CAS to switch to the latest iteration of the Spring Boot framework, namely the 2.x series. You can read all about Spring Boot 2 here.

Given the impact and utility of the framework in the CAS codebase, a rather large number of changes have had to be introduced in order to achieve a successful upgrade and keep as much of the current functionality as possible. However, a number of areas in CAS are negatively impacted by this upgrade some of which are more visible than others and sometimes for the better. These areas include are but not limited to CAS metrics, actuator/admin endpoints as well as their security and protection strategy.

It is quite likely that CAS would ultimately switch to Spring Boot 2.1.x to take full advantage of Java 11 support.

Metrics

As part of the Spring Boot v2 upgrade, CAS metrics are cleaned up as much as possible to delegate the entire task of capturing and recording metrics to Spring Boot, which internally delegates that functionality by auto-configuring components from the micrometer project. This is an application metrics facade for the most popular monitoring tools whose connection information is entirely controlled by specific properties and settings provided by Spring Boot. In this area, CAS only begins to prepare the deployment environment with the right set of dependencies and libraries and then gets out of the way, allowing micrometer and native Spring Boot functionality to take over.

While a large set of options are supported by micrometer and auto-configured by Spring Boot to capture and store metrics, as a result of this change support for services such as MongoDb, Redis and such are removed from CAS given support for the equivalent components in Spring Boot is removed. However, note that micrometer continues to add support for newer services and target systems and by simply keeping the dependencies up-to-date and relevant, those options would automatically become available to CAS.

Endpoints

Actuator endpoints, known in CAS as admin endpoints, let you monitor and interact with your application. Spring Boot includes a number of built-in endpoints and lets you add your own. For example, the health endpoint provides basic application health information. Spring Boot 2 brings a brand new endpoint infrastructure that allows you to define one or several operations in a technology independent fashion with support for Spring MVC, Spring WebFlux and more.

This means while the endpoints provided by Spring Boot will transition quite nicely over to CAS 6, those that are provided by CAS needed to be redesigned again to lend themselves to the new technology-agnostic strategy. In this new model, endpoints exhibit the following traits:

• Each endpoint can be individually enabled or disabled and a global default is available to control this behavior en mass.
• The security of each endpoint is entirely controlled by Spring Security, once and if found in the application bundle on the classpath. More on this later in the following section.
• Each endpoint may be individually chosen for exposure over the web.
• By default, endpoints are exposed over HTTP under the /actuator path by using the ID of the endpoint. However, endpoints can be remapped. For example, the following settings remap /actuator/health to /healthcheck:

management.endpoints.web.base-path=/
management.endpoints.web.path-mapping.health=healthcheck

To learn more about endpoints, monitors and health indicators from the Spring Boot perspective, please review this document.

Endpoint Security

Endpoint security in Spring Boot v2 and by extension CAS receives a complete overhaul. All endpoints are considered disabled and sensitive by default, protected by a pair of pre-defined master credentials in CAS properties. Spring Boot 2.0 does not provide separate auto-configuration for user-defined endpoints and actuator endpoints with a rather overloaded sensitive property. All that functionality is handed off to Spring Security.

When Spring Security is on the classpath, the auto-configuration secures all endpoints by default. CAS relies on Spring Security’s content-negotiation strategy to determine whether to use httpBasic or formLogin, and security of endpoints is extended by CAS configuration to determine the access level and permissions of each endpoint. There will be follow-up guides and posts about how to get endpoints secured and available for proper access but for now, this document should be a decent starting point.

CAS Command-line Shell

The CAS command-line shell, as a result of upgrading to the latest Spring Shell version, is impacted such that basic command-line options available in the non-interactive version of the shell are now removed. This means that you may still log into the shell and work with available CAS commands as you did interactively, taking advantage of features such as command history, tab completion, etc.

Dynamic SAML2 Metadata

Dynamic SAML2 metadata management via JPA and MongoDb is now able to support and store SAML2 identity provider metadata artifacts. Support for additional storage options may be added in future on demand.

Webflow Decorations

Learn how to fetch and display data dynamically from external data sources and endpoints and pass those along to the webflow by reviewing this guide.

Adaptive Authentication IP Intelligence

Adaptive Authentication gains support to examine client IP addresses using a variety of strategies to determine whether requests should be allowed or rejected.

Azure MFA Integration

The integration with Microsoft’s Azure multifactor authentication, previously marked as deprecated functionality, is now removed from CAS.

Google Authenticator Account Management

Accounts registered with Google Authenticator can now be monitored and managed administratively via CAS monitoring capabilities.

OAuth & OpenID Connect JSON Output

The jsonFormat property assigned to each OAuth or OpenID Connect services is now removed and JSON is now made the default output syntax.

OAuth Device Flow

OAuth device flow is now supported.

OAuth Proof Key Code Exchange (PKCE)

OAuth PKCE flow is now supported.

CAS as Multifactor Authentication Provider

CAS gains the ability to act as a simple multifactor authentication provider, issuing tokens on its own and sharing them with the end-user via email and/or text messages.

Couchbase Audits

Couchbase is now supported for CAS audit logs.

SAML2 Metadata Health Status

Status of SAML metadata assigned to a SAML service can now be reported back as part of the CAS health monitoring.

OAuth Token Introspection

CAS OAuth support can now lend itself to token introspection. The semantics of this functionality are identical to that of OpenID Connect.

YubiKey Account Management

Accounts registered with YubiKey Authentication can now be monitored and managed administratively via CAS monitoring capabilities.

Nexmo SMS Integration

CAS can now integrate with the Nexmo platform for sending text messages.

Small Stuff

• Delegated to the OpenID Connect provider for authentication now supports a new tenant option.
• Aspects of OpenID Connect discovery profile, such as supported claim types, signing algorithms, etc can now be customized via CAS settings.
• While generating JWTs, a typ header parameter is now specified.
• The signing algorithm of OpenID Connect services can now be defined for each RP.
• Delegated authentication should correctly take advantage of the unauthorizedUrl field assigned to a service definition.
• Delegated authentication should hide aspects of the CAS user interface while auto-redirecting to a provider.
• Additional audit points are now provided for OAuth functionality to capture access token requests and responses as well as device codes.
• The multifactor trusted devices endpoint can now fetch registered devices linked to a user name.
• Internal APIs used to manage Google Authenticator tokens and accounts are improved to support additional removal and counting ops.
• Consistent package import order rules are now applied across the codebase and enforced by Checkstyle.
• CAS is now using SonarQube for static analysis and extra code quality measures.
• A ton of improvements to the Travis CI test harness to ensure CAS builds can execute as efficiently as possible while running integration tests.
• Binary attribute values should now be properly encoded in CAS validation payload.
• Acceptable Usage Policy and Interrupt Notification features of CAS are now wired up to play nice with delegated authentication flow.
• SPNEGO authentication properties are now split into two sections were one deals with system-level settings and the other controls a collection of SPNEGO authntication attempts with support for multiple service principals, etc.
• Small number of adjustments to ensure CAS cookie management can optionally control cookie session-pinning.

Library Upgrades

• Java
• Spring
• Spring Boot
• Apache Tomcat
• Spring Boot Admin
• JUnit
• Kryo
• JAXB
• Swagger
• Eureka
• InfluxDb
• Apache Ignite
• MongoDb Driver
• MariaDb Driver
• PostgreSQL Driver
• Couchbase
• Hazelcast
• MySQL
• Guava
• Amazon SDK
• Twilio
• Pac4j
• Nimbus JWT
• Cassandra Driver
• Font Awesome
• Bootstrap

Resources

• Documentation
• Release Schedule
• Release Policy

Get Involved

• Start your CAS deployment today. Try out features and share feedback.
• Better yet, contribute patches.
• Suggest and apply documentation improvements.

Credits

Big thanks to all who participate in the development of this release to submit patches and contribute improvements. Keep’em coming!

Misagh Moayyed