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 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
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
- 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.
pom.xml of the overlay, adjust the following tag to match below:
gradle.properties of the overlay, adjust the following setting to match below:
- A boolean flag is now exposed in CAS settings to toggle Google reCAPTCHA behavior.
- Scratch codes for Google Authenticator multifactor authentication are now properly recognized as valid tokens.
- A series of small bug fixes to ensure claims and scopes are properly recognized and released via the OpenID Connect protocol.
- 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.
- Thanks to @pdrados, risk-based authentication gains a few new fixes when CAS begins to calculate the authentication risk factor based on date/time.
- Thanks to @robertoschwald, the CAS protocol specification is slightly revved to provide a few fixes to the XSD schema and to remove the
- 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.
- 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).
- LDAP support is slightly enhanced with a new setting to enable dereferencing aliases.
- The CAS internal Gradle build is integrated with Google’s error-prone plugin to detect anomalies and prevent bugs.
- References to Spring’s
VelocityEngineFactoryare removed and CAS attempts to create its own
VelocityEngineinstance 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.
- CAS startup banner details, such as CAS version or commit id, etc are now also included in the
- The HTTP security filter is made more flexible by accepting values for
- The embedded Apache Tomcat container now supports a few additional filters such as CSRF and Remote-Address.
- 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.
- CAS is now able to inject arbitrary headers into the response where needed to account for custom workflows and security settings.
- The configuration metadata is slightly improved to ensure metadata for inherited fields is properly generated.
- 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
- A number of documentation improvements by @dstepe, @mac-reid.
- Thanks to @dacurry-tns, connections to MongoDb are now improved to better handle
- Thanks to @mbenson, the CAS BOM is now improved to include all CAS modules.
- Thanks to @gledsonrabelo, the prefix for proxy tickets is now fixed to be
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:
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.
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
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
timeout, etc are moved to a common block and take the form of:
configurationKey can either be
As part of the cleanup, the property
userFilterthat dealt with LDAP authentication filters and queries is now deprecated and replaced with
searchFilterto be consistent with all other LDAP integration modules and features.
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.
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:
OUT_OF_SERVICE many of which are by default provided by Spring Boot.
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.
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
- Spring Boot
- Spring Cloud
- AWS Java SDK
- Azure CosmosDb
- Apache Commons
- Apache CXF
- Apache Tomcat
- Apache Fediz
- Google Maps
- Apache HttpClient
- Apache Ignite
- Apache Log4j
- MariaDB Driver
- Apache Velocity
- Start your CAS deployment today. Try out features and share feedback.
- Better yet, contribute patches.
- Suggest and apply documentation improvements.
Big thanks to all who participate in the development of this release to submit patches and contribute improvements. Keep’em coming!