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.1.0 GA was released on May 27th 2017. Since then,
the project has been moving forward with development of the next feature release
that is tagged as
5.2.0. This post intends to highlight some of the improvements
and enhancements packed into the second release candidate in the
You can read more about the previous release candidate here.
- Default Theme For Services
- Authentication Plan Configurators
- Authentication Graph
- Dynamic Authentication Policies
- Configuration Documentation
- Configuration Metadata Server
- Apache Fortress Integration
- SQRL Authentication Support
- Encryption/Signing Log Messages
- Clustered Service Replication
- Gradle Build Performance
- Service Definition File Checking
- Scripted Username Providers
- Attribute Consent
- SAML2 Metadata Expiration
- Swagger Documentation
- CAS Demos
- Multimapped Attributes
- Password Management
- REST Attribute Repository
- Scripted Attribute Repositories
- Surrogate Authn via JDBC
- Library Upgrades
- What’s Next?
- Get Involved
- Das Ende
- Service access strategies based on principal attributes should now correctly be enforced prior to jumping into subsequent factors of authentication.
- Thanks to @gbatalski, JWT authentication in CAS is now able to support base64-encoded secrets.
- Thanks to @benht, expired tickets are now properly removed from CAS when using MongoDb ticket registry.
- Thanks to @klewczuk, refresh tokens are no longer auto-generated when using grant type
- Thanks to @WhiteMarlin, a number of reference to
Jasigare now removed from CAS language bundles.
- Database drivers are now defined to be available at
runtimevia the published POM, so they can be included in the overlay.
- Groovy/Scripting utilities are cleaned up to use a consistent strategy across the codebase where needed.
- MongoDb Ticket/Service registry configuration is now able to take advantage of distinct unique group of settings.
- YAML service registry bean is now properly renamed so it can honor
- Thanks to @pdrados, throttled authentication attempts are better explained in the UI via a new http status code.
- Service registry initialization from JSON is now able to honor service definitions found at the path specified via settings, rather than only loading those found on the classpath’s
- Thanks to @bbooth, password management flows now correctly register a password update state.
- Thanks to @swoeste, URL validation is now provided an option to support
localhosttype urls, when dealing with things such as SLO.
- Thanks to @tduehr, generating random strings that specially affect ticket ids and such are now improved to use more secure algorithms and strategies.
Default Theme For Services
Thanks to @swoeste, the CAS default theme is now also consulted by registered services. Services still have the ability to define a specific theme and have it be resolved by the theme resolution machinery, but if no theme is defined, services are now given the ability to fall back onto the default theme specified by
Authentication Plan Configurators
All configuration components in CAS that register authentication handlers into the runtime engine have now become their own
@Bean marked as
@Conditional for easier overrides.
The CAS statistics page now boasts the ability to present authentication events as a chart.
Dynamic Authentication Policies
Additional authentication policies are now made available to check account status and state via Groovy and REST endpoints. This is useful in the event that the underlying authentication scheme does not provide a way to check for account status and you wish to resort to more elaborate means of enforcing policies dynamically. See this guide for more info.
The entire CAS configuration model is now annotated and documented using Javadocs. The build process is also augmented to scan the configuration model and produce a repository of all settings, groups, etc along with their description, values, hints and documentation. This repository is then later used by the CAS configuration metadata server to allow deployers to query settings via REST or CLI tools. In future releases, GUIs will also be able to auto-initialize a module using relevant settings that are sorted and ranked from the same repository instance.
What does this mean for you?
In cleaning up the configuration model and in order to maximize reuse, a number of duplicate settings were moved around and refactored so as so to allow centralization of documentation items without having to duplicate notes and descriptions. At a high level, the following category of settings are cleaned up and made reusable:
signingKeysettings were duplicated throughout the codebase. These are now cleaned up so that for instance every component that requires access to crypto-related settings now hosts
crypto.signingsettings that house keys and settings in a reusable way.
The same strategy is also applied to scheduler-related tasks that define
startUpDelaywhere these are moved to a parent reusable component that is usually noted by the
schedulekey name (i.e.
Properties that referenced a Spring-managed resource prior to this release took the form of
cas.setting.config.location. These are now cleaned up to simply define the resource as
Explicit properties are now made available for both JSON and YAML service registries in form of
In your own local configuration, you will need to adjust key names to match the new locations.
Why not use plain markdown instead?
This all means that rather than documenting every single setting and key in the project documentation via markdown, the project documentation specially for settings and configuration now sits right beside the setting itself. This not only turns documentation into working code, and it not only provides additional processing power and querying to be done on the setting, it furthermore allows the codebase to automate the requirement of documentation for settings as well and fail the build in case something goes undocumented.
Note that this is just a very modest starting point and the field descriptions that now are available for settings will continually need to be improved, revised and expanded. Writing good documentation for adopters who step forward with varying levels of skill is a very difficult and delicate task and good-enough is usually never enough. You’re encouraged to continually improve the docs and explain things to the level you deem appropriate for your own audience.
Configuration Metadata Server
The metadata server is an interactive CLI tool that allows one to query the CAS configuration metadata and learn more about propeties, groups, etc. The configuration metadata repository is built and generated for every CAS build and release and the metadata server is then simply tasked to query the database and respnd to commands. The server ships with both a CLI as well as interactive shell interface.
See this guide for more info.
Apache Fortress Integration
Thanks to @yudhik, CAS gains integration support with Apache Fortress. Apache Fortress is a standards-based access management system that provides role-based access control, delegated administration and password policy services with LDAP.
Read more about the CAS integration here.
SQRL Authentication Support
Modest amount of work has been done to begin support for the SQRL Protocol. This is very much in an experimental state as both the specification as well as client implementations today are rather incomplete and in flux. This will eventually be ironed out, provied the finalization of the protocol spec itself.
Encryption/Signing Log Messages
In certain cases where CAS begins to generate keys for signing/encryption tasks, there are now additional log messages that indicate the setting name under which the newly generated key must be placed.
2017-07-24 07:29:26,249 WARN [org.apereo.cas.util.cipher.BaseStringCipherExecutor] - <Secret key for encryption is not defined for [Ticket-granting Cookie]; CAS will attempt to auto-generate the encryption key> 2017-07-24 07:29:26,259 WARN [org.apereo.cas.util.cipher.BaseStringCipherExecutor] - <Generated encryption key [...] of size  for [Ticket-granting Cookie]. The generated key MUST be added to CAS settings under setting [cas.tgc.crypto.encryption.key].>
Clustered Service Replication
CAS gains the ability to replicate and redistribute registered service definition files across the cluster via Hazelcast and more. See this guide to learn more.
Gradle Build Performance
Internally, the CAS Gradle build is readjusted to ensure required build repositories are only made available to submodules that need them for artifacts, which should allow for much faster load times when the project is loaded into a development environment in a non-offline mode manner.
Service Definition File Checking
In the event that a resource-based service registry is employed (i.e. JSON, YAML), additional checks are now built in to ensure that the service files are named appropriately.
Scripted Username Providers
At last, CAS provides the ability to enforce user-informed consent upon attribute release.
SAML2 Metadata Expiration
SAML2 services now gain the ability to define an expiration duration for their metadata. If left undefined, a global default will be used for all resolved metadata in the cache.
CAS is now able to auto-generate API documentation for all endpoints, controllers and REST services, via Swagger.
A number of URLs for CAS demos running on Heroku have changed.
CAS gains the ability to map and rename the same attribute definition multiple times to different names. This can be done either as part of attribute retrieval or at release time.
Password management functionality in CAS is now broken up into distinct modules depending on the backened storage service in use.
REST Attribute Repository
CAS gains the ability to contact REST endpoints to resolve attributes.
Scripted Attribute Repositories
Surrogate Authn via JDBC
CAS gains the ability to support surrogate authentication via JDBC resources.
- Apache Tomcat
- Spring Boot admin
- Spring Boot
- Amazon SDK
- Spring Cloud
- Apache CXF
- Postgresql driver
- MariaDb driver
- MySQL driver
- Apache Cassandra
We are all working to make sure the CAS
5.2.0 release is on schedule.
- Start your CAS deployment today. Try out features and share feedback.
- Better yet, contribute patches.
- Suggest and apply documentation improvements.
A big hearty thanks to all who participated in the development of this release to submit patches, report issues and suggest improvements. Keep’em coming!