CAS 5.3.0 RC1 Feature Release

The official CAS 5.2.0 GA was released on November 27th, 2017. Since then, the project has been moving forward with development of the next feature release that is tagged as 5.3.0. This post intends to highlight some of the improvements and enhancements packed into the first release candidate in the 5.3.0 series.

The in-development documentation of CAS 5.3.0 is available here. The release schedule is also available here. The release policy is available here.

• Shake Well Before Use
  • Apache Maven
  • Gradle
• Minors
• CosmosDb Service Registry
• SAML2 Service Providers
• Delegated AuthN SAML2 Metadata Endpoints
• Groovy Access Strategy
• Service Replication via Hazelcast
• Global Attribute Caching Policies
• Documentation CleanUp
• Dynamic Metadata Management
• Externalized Views
• Health Indicators & Monitors
• HashiCorp Consul
• Hazelcast AWS EC2 Discovery
• Multifactor Authentication Trigger Per Service Via Groovy
• Microsoft Azure’s KeyVault Secrets
• Response Type Per Service
• Delegated Authentication Access Policy
• Shibboleth Attribute Resolver
• Splunk Logging
• U2f Authentication Registration Record Encryption
• Library Upgrades
• Get Involved
• Das Ende

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. In order to start experimenting with release candidates, use the following strategies.

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.

Apache Maven

In the pom.xml of the overlay, adjust the following tag to match below:

<cas.version>5.3.0-RC1</cas.version>

Gradle

In the gradle.properties of the overlay, adjust the following setting to match below:

cas.version=5.3.0-RC1

Minors

1. A boolean flag is now exposed in CAS settings to toggle Google reCAPTCHA behavior.
2. Scratch codes for Google Authenticator multifactor authentication are now properly recognized as valid tokens.
3. A series of small bug fixes to ensure claims and scopes are properly recognized and released via the OpenID Connect protocol.
4. Thanks to @Thaslin,delegating authentication to ADFS gains support for WCTX while handling concurrent requests. This problem manifests itself when multiple iframes redirect to CAS at nearly the same time. Since only one static session key was used for the CAS service, all requests were redirected to the same service URL after authentication success. Using the WCTX parameter as part of the session key solves this problem.
5. Thanks to @pdrados, risk-based authentication gains a few new fixes when CAS begins to calculate the authentication risk factor based on date/time.
6. Thanks to @robertoschwald, the CAS protocol specification is slightly revved to provide a few fixes to the XSD schema and to remove the memberOf attribute.
7. A number of improvements to URL validators by @swoeste to support unknown yet valid TLDs. Regex support is now added to CAS HTTP configuration to ensure URL authorities can be correctly verified based on that pattern.
8. Thanks to @hdeadman, the command-line shell is slightly improved when it’s asked to add properties for a configuration group that is not strictly controlled by CAS itself. (i.e. add-property -group tomcat).
9. LDAP support is slightly enhanced with a new setting to enable dereferencing aliases.
10. The CAS internal Gradle build is integrated with Google’s error-prone plugin to detect anomalies and prevent bugs.
11. References to Spring’s VelocityEngineFactory are removed and CAS attempts to create its own VelocityEngine instance required and used to support SAML and friends. This is also a prepping move before CAS switches over to Spring 5 where Velocity functionality is now absent.
12. CAS startup banner details, such as CAS version or commit id, etc are now also included in the info endpoint.
13. The HTTP security filter is made more flexible by accepting values for X-FRAME-OPTIONS and X-XSS-PROTECTION.
14. The embedded Apache Tomcat container now supports a few additional filters such as CSRF and Remote-Address.
15. CAS audit logs see a few small improvements when data is formatted as JSON. Ticket validation events in the audit log are also able to show the authenticated principal and the collection of attributes released to the application as part of the assertion.
16. CAS is now able to inject arbitrary headers into the response where needed to account for custom workflows and security settings.
17. The configuration metadata is slightly improved to ensure metadata for inherited fields is properly generated.
18. When securing admin pages and dashboard in CAS via IP address, there is now the ability to determine the IP via alternative headers such as X-Forwarded-For.
19. A number of documentation improvements by @dstepe, @mac-reid.
20. Thanks to @dacurry-tns, connections to MongoDb are now improved to better handle clientUri settings.
21. Thanks to @mbenson, the CAS BOM is now improved to include all CAS modules.
22. Thanks to @gledsonrabelo, the prefix for proxy tickets is now fixed to be PT.

CosmosDb Service Registry

CAS service definitions can now be managed and controlled via Microsoft Azure’s CosmosDb.

SAML2 Service Providers

The following new SAML2 service providers are now supported by CAS out of the box:

• GitLab
• Hipchat
• AppDynamics

Delegated AuthN SAML2 Metadata Endpoints

When delegating authentication to external SAML2 identity providers, CAS is able to present both the SP (CAS) and the IdP metadata via dedicated endpoints.

Groovy Access Strategy

Service access strategy policies can now take advantage of a Groovy script for more dynamic rules.

Service Replication via Hazelcast

In the event that CAS service definitions are not managed globally via a centralized store, service definition files managed as JSON or YAML files can be replicated across the CAS cluster via Hazelcast in addition to the native tooling options of the CAS platform.

Global Attribute Caching Policies

Attribute release caching in CAS may certainly be done on a per-service basis. In this release, CAS provides a strategy for caching attributes at a more global level specifically at release time.

Documentation CleanUp

A large number of CAS settings that are shared and common across modules are cleaned up to only be referenced once in a common area, pointing to a specific configuration key. This is a gradual effort and will take some time to complete.

For instance, when it comes to MongoDB support there are a large number of CAS modules and components that support and integrate with it whose settings, structurally, are very much shared. Consider the duplicated settings below for features feature1 and feature2:

cas.feature1.mongo.host=localhost1
cas.feature1.mongo.timeout=2000

cas.feature2.mongo.host=localhost2
cas.feature2.mongo.timeout=4000

Instead, the common settings such as host, timeout, etc are moved to a common block and take the form of:

${configurationKey}.mongo.host=localhost1
${configurationKey}.mongo.timeout=2000

…where the configurationKey can either be cas.feature1 or cas.feature2, etc.

Dynamic Metadata Management

Managing service provider metadata documents, especially for bilateral integrations can now be done with the likes of MongoDB, SQL databases or Groovy, etc. See this guide for more info.

Externalized Views

CAS UI pages and that of Thymeleaf can now be loaded from external locations outside the web application context. While this was always a possible, this release candidate provides the ability to conditionally load views from an external path when found, and otherwise fall back to the default location inside the web application.

Health Indicators & Monitors

CAS for some time has had the ability to monitor external systems and data sources such as LDAP, Memcached, etc. In this release candidate, the legacy CAS Monitor API is removed in favor of Spring Boot’s native HealthIndicator components. CAS monitors are removed from the /status page and moved to the Spring Boot’s /health endpoint. Note that the new endpoint by default does not show details of the monitors configured unless the request is an authenticated one with Spring Security. This behavior of course can be controlled via CAS settings.

Note that as a result of this change, status codes that are returned by CAS have changed to include: UNKNOWN, UP, DOWN, WARN and OUT_OF_SERVICE many of which are by default provided by Spring Boot.

HashiCorp Consul

Thanks to Spring Cloud, CAS can now be tightly integrated with HashiCorp’s Consul for service discovery, health checks as well as configuration management via Consul’s key-value store. See this guide for more info.

Hazelcast AWS EC2 Discovery

Hazelcast support in CAS is now equipped to handle AWS EC2 auto-discovery. It is useful when you do not want to provide or you cannot provide the list of possible IP addresses for the cluster members. Furthermore, you may now specify a partitioning group configuration that may be zone-aware. See this guide for more info.

Multifactor Authentication Trigger Per Service Via Groovy

Multifactor authentication triggers per applications can now be more dynamically decided via a Groovy script. See this guide for more info.

Microsoft Azure’s KeyVault Secrets

Azure Key Vault Secrets can now act as a storage mechanism for CAS properties and settings in conjunction with Spring Cloud. See this guide for more info.

Response Type Per Service

The CAS protocol likely since its inception has provided support for a method parameter whose value would allow CAS to respond back to the service/application with a ticket via a redirect, a POST, etc. This behavior can now be applied to a registered service definition, controlling application behavior and expectations centrally. If you have a group of individual applications who all expected CAS to contact them back with a POST, you may group them together in a definition and set the responseType accordingly rather than having each individual application specify a method=POST in the authentication request.

Delegated Authentication Access Policy

In the event that CAS is allowed and configured to delegate the authentication request to an external provider such as a SAML2 IdP, you may now assign policies to registered service definitions in the CAS service registry to let each service control the set of authorized external identity providers. This behavior is enforced in the UI and while tickets are generated or validated.

See this guide for more info.

Shibboleth Attribute Resolver

Support for resolving attributes using a Shibboleth IdP’s attribute-resolver.xml is now removed.

Splunk Logging

Support for publishing logs to Splunk is now included in this release. CAS is not quite taking advantage of native Splunk logging capabilities to format messages and that bit surely might receive more attention in future releases.

U2f Authentication Registration Record Encryption

Support for encryption/decryption of U2F authentication registration records stored in RDBMS as well as MongoDB repositories has been added via new properties

Library Upgrades

• Gradle
• Hibernate
• AspectJ
• Spring
• Spring Boot
• Spring Cloud
• AWS Java SDK
• Hazelcast
• HikariCP
• Authy
• Azure CosmosDb
• Cassandra
• Apache Commons
• Apache CXF
• Apache Tomcat
• Eureka
• Apache Fediz
• Geo2IP
• Maxmind
• Google Maps
• Apache HttpClient
• Apache Ignite
• Couchbase
• Jose4J
• Apache Log4j
• MariaDB Driver
• Mockito
• Apache Velocity
• OpenSAML
• Pac4j
• SemVer
• Zipkin
• Sleuth

Get Involved

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

Das Ende

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

Misagh Moayyed