This post is not official yet and may be heavily edited as CAS development makes progress. Watch for further updates.
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.
- Authentication Plan Configurators
- Dynamic Authentication Policies
- Configuration Documentation
- Configuration Metadata Server
- Apache Fortress Integration
- SQRL Authentication Support
- Encryption/Signing Log Messages
- Build Repositories
- Service Definition File Checking
- Scripted Username Providers
- Attribute Consent
- 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.
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.
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. For example, various
signingKey settings were duplicated throughout the codebase, which if not cleaned up and made reusable, would have required duplicate documentation and triple effort. These are now cleaned up so that for instance every component that requires access to crypto-related settings now hosts
crypto.signing settings that house keys and settings in a reusable way. The same strategy is also applied to scheduler-related tasks that define
startUpDelay where these are moved to a parent reusable component that is usually noted by the
schedule key name (i.e.
cas.xyz.schedule.repeatInterval rather than
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 confguration 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 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
Apache Fortress Integration
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].>
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.
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
- 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!