CAS 5.2.0 RC2 Feature Release

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 5.2.0 series.

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

You can read more about the previous release candidate here.

• Minors
• Default Theme For Services
• Authentication Plan Configurators
• Authentication Graph
• Dynamic Authentication Policies
• Configuration Documentation
  • What does this mean for you?
  • Why not use plain markdown instead?
• 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

Minors

• 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 refresh_token.
• Thanks to @WhiteMarlin, a number of reference to Jasig are now removed from CAS language bundles.
• Database drivers are now defined to be available at runtime via 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 @Conditional annotations.
• 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 services directory.
• 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 localhost type 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 cas.theme.defaultThemeName.

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.

Authentication Graph

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.

Configuration Documentation

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:

• Various encryptionKey and signingKey settings 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.encryption and crypto.signing settings that house keys and settings in a reusable way.

• The same strategy is also applied to scheduler-related tasks that define repeatInterval and 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 cas.xyz.repeatInterval).

• 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 cas.setting.location.

• Explicit properties are now made available for both JSON and YAML service registries in form of cas.service-registry.json and cas.service-registry.yaml.

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 [256] 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

CAS gains the ability to use Java’s native scripting functionality for username attribute providers to support Groovy, Javascript and Python scripts.

Attribute Consent

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.

Swagger Documentation

CAS is now able to auto-generate API documentation for all endpoints, controllers and REST services, via Swagger.

CAS Demos

A number of URLs for CAS demos running on Heroku have changed.

Multimapped Attributes

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

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

CAS gains the ability to use Java’s native scripting functionality for attribute repository sources to support Groovy, Javascript and Python scripts to resolve and retrieve attributes.

Surrogate Authn via JDBC

CAS gains the ability to support surrogate authentication via JDBC resources.

Library Upgrades

• Apache Tomcat
• Eureka
• Spring Boot admin
• Spring
• Spring Boot
• Pac4J
• Amazon SDK
• Spring Cloud
• Jose4J
• Apache CXF
• Postgresql driver
• MariaDb driver
• MySQL driver
• Couchbase
• Apache Cassandra
• Gradle
• Hazelcast
• Ldaptive

What’s Next?

We are all working to make sure the CAS 5.2.0 release is on schedule.

Get Involved

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

Das Ende

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!

Misagh Moayyed