CAS 6.2.0 RC4 Feature Release


Collaborate
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 6.1.0 GA was released in October 2019. Since then, the project has been moving forward with the development of the next feature release that is tagged as 6.2.0. Please review the release policy to learn more about the scope of the release. This post intends to highlight some of the improvements and enhancements packed into the fourth release candidate in the 6.2.0 series.

If you are looking for additional info on the previous release candidate, please see this post.

Apereo Membership

If you benefit from Apereo CAS as free and open-source software, we invite you to join the Apereo Foundation and financially support the project at a capacity that best suits your deployment. Note that all development activity is performed almost exclusively on a voluntary basis with no expectations, commitments or strings attached. Having the financial means to better sustain engineering activities will allow the developer community to allocate dedicated and committed time for long-term support, maintenance and release planning, especially when it comes to addressing critical and security issues in a timely manner. Funding will ensure support for the software you rely on and you gain an advantage and say in the way Apereo, and the CAS project at that, runs and operates. If you consider your CAS deployment to be a critical part of the identity and access management ecosystem, this is a viable option to consider.

Get Involved

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. Note that CAS releases are strictly time-based releases; they are not scheduled or based on specific benchmarks, statistics or completion of features. To gain confidence in a particular release, it is strongly recommended that you start early by experimenting with release candidates and/or follow-up snapshots.

In order to start experimenting with release candidates, at any given time, you should be able to append -SNAPSHOT to the CAS version in order to take advantage of snapshot builds as changes are made and published.

Resources

Overlay

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

cas.version=6.2.0-RC4
System Requirements
There are no changes to the minimum system/platform requirements for this release.

New & Noteworthy

WebAuthn Support

WebAuthn Support continues to progress at a slow and steady pace. While the changes are still in progress and have not landed in the codebase yet, there is a fair amount of progress made to make WebAuthn available as another form of multifactor authentication in CAS. It is expected for this feature to finalize before the GA release.

JPA Implementations

The Hibernate framework has always been the default JPA implementation in CAS, and an assumed dependency for most JPA-related modules. In this release candidate, Hibernate support is extracted out into its own module, allowing alternative JPA implementations to be provided at runtime via JpaBeanFactory instances. As a result, support is now provided for both Hibernate and EclipseLink while Hibernate continues to be the default.

SAML2 Metadata Management

Managing SAML2 metadata via REST is now given the ability to manage identity provider metadata and keys as well, for the CAS server itself globally or a given service definition if necessary.

Deprecation of Script Engines

Support for Script Engines provided by the Java platform is deprecated and scheduled to be removed. Native support for Groovy, independent of the JDK platform continues to be available and a viable choice for scripting options. Support for Ruby has also been removed, while Javascript, Python and Groovy are still available though deprecated as part of the JDK’s ScriptEngine capability.

REST Service Registry Entity Mapping

When interacting with an external REST API, instances of RegisteredServiceEntityMapper can now be injected into the runtime to translate CAS RegisteredService objects back and forth between CAS and APIs. The mapping should simplify the integration, allowing CAS to handle POJO transforms rather than expecting external APIs to be aware of CAS data models and API changes, if any.

Test Coverage via CodeCov

CAS test coverage across all modules in the codebase has now reached 70% and continues to climb. Additional validation rules are also applied to fail all pull requests that fall below this threshold. This area will be closely monitored and improved as progress is made with the goal of hopefully reaching at least 80% before the final GA release. Of course, this will not be a blocker for the final release.

Global Multifactor Provider Selection Menu

Multifactor provider selection menus can now be activated using global triggers in addition to activation options using the per-service approach. As an example, users may be allowed to choose between Google Authenticator and CAS SimpleMFA for multifactor, regardless of affiliation, application, etc using cas.authn.mfa.globalProviderId=mfa-simple,mfa-gauth.

Webflow Auto configuration

Auto configuration of webflow components that prepare the CAS runtime for multifactor authentication can now be further customized by instances of CasMultifactorWebflowCustomizer by other participating or candidate modules to further augment the state of webflow.

Updated Integration Tests

The integration tests executed by the Travis CI environment are updated to run against the following components:

  • MongoDb 4.2.x
  • Apache CouchDb 3.0.x
  • Couchbase 6.5.x
  • MariaDb 10.5.x
  • Postgres 12
  • Microsoft SQL Server 2019-CU4-ubuntu-16.04
  • Apache Cassandra 3.11.6

Principal Resolution via Person Directory

Principal resolution handled by Person Directory is now able to pass along query attributes to the underlying attribute repository that contain not only the query identifier as the username, but also principal attributes collected from authentication sources. The collection of attributes can particularly be passed down to Groovy scripts that need to cascade execution of queries.

As part of this change, the aggregation of query results when multiple attribute repositories are in use can now also be cascaded across repositories, in additional to the previous and still-default merging approach. Please note that in general, ldap search filters would be better off specifying the attribute name to use in the query (e.g. {username}) rather than {0} or {user}. This allows one to do complex multi-attribute queries as long as you don’t use {0} and {user}.

Additionally, attribute repository sources that are bootstrapped and managed by Person Directory are now marked as @Conditional only to picked up and created if the appropriate CAS configuration is defined (LDAP url, database connection strings, etc).

Acceptable Usage Policy

Acceptable usage policy support is given a face-lift to be able to properly load policy terms and text from CAS language bundles, or via external sources such as Groovy or REST APIs.

Additionally, policy sources and storage services are now marked as @Conditional only to picked up and created if the appropriate CAS configuration is defined (LDAP url, database connection strings, etc).

WATCH OUT!
This may be a breaking change specially if you were using Groovy to manage terms of use decisions. Consult the CAS documentation and adjust your script accordingly to match the manual.

Authentication Policy Per Service

The required_handlers field for service definition has been deprecated in favor of authenticationPolicy, to allow one to define richer configuration and metadata and instruct the CAS authentication engine more forcefully when it comes to processing application definitions.

As of this re-design, authentication policies can be assigned to service definitions to override the global defaults.

WATCH OUT!
While the old field is not removed, and CAS should attempt to seamlessly transition old configuration into the new equivalent, it's best to take explicit action and migrate the setting now to the new syntax and format. The required_handlersfield will be removed at some point in a future CAS version.

SAML2 AssertionConsumerService Handling

An important improvement to the handling of in SAML2 authentication requests to better align the CAS implementation with the SAML2 specification; if the <AuthnRequest> is not authenticated and/or integrity protected, the information in it MUST NOT be trusted except as advisory. Whether the request is signed or not, the identity provider MUST ensure that any <AssertionConsumerServiceURL> or <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack.

OAuth / OpenID Connect Token Revocation

A fairly significant change; Token revocation support is now extended supported for both OAuth and OpenID Connect protocols. Additionally, support for public OAuth clients has been added, and refresh token revocation can now revoke all related access tokens.

JDK 14 Compatibility

Now part of Oracle’s Quality Outreach Program, CAS is able to build and run successfully against the latest versions of JDK 14. The JDK baseline requirement continues to be set at JDK 11, and we are simply keeping up with JDK releases to ensure CAS can correctly switch the baseline requirement when deemed necessary.

OpenSAML v4

The SAML functionality of the CAS server that handles support for SAML 1.1 and SAML 2 as an identity provider is now upgraded to use OpenSAML v4. Likewise, delegating authentication to external SAML2 identity providers via the Pac4j library has also been upgraded. As a result, a number of dependencies and components in these areas have been cleaned up and removed to make the upgrade possible.

REST-based Authentication Policy

The properties structure for the RESTful authentication policy are revamped slightly to match other REST-based features in CAS. As a result, the authentication policy is now given the ability to support basic authentication.

Multifactor Authentication with Trusted Device

Support for multifactor authentication with trusted devices has improved to allow the user to select the expiration date/time of the device.

image

Records that are used to track devices are also modified to keep track of the device expiration date/time. As a result of this change, the strategy for generating device record keys is altered to make sure records can be successfully tracked, stored and fetched for all storage options. You can restore the old key generation strategy using cas.authn.mfa.trusted.keyGeneratorType=legacy.

OpenID Connect Single Logout

Support for OpenID Connect Single Logout based for back-channel and front-channel are now made available. Back and front channel logouts are implemented with the use of the session id (which is the SHA of the ticket-granting ticket id).

OpenID Connect JWKS Configuration

JWKS-related settings for OpenID Connect support in CAS are moved to their own configuration namespace under cas.authn.oidc.jwks:

# cas.authn.oidc.jwks.jwks-file
# cas.authn.oidc.jwks.jwks-cache-in-minutes
# cas.authn.oidc.jwks.jwks-key-size
# cas.authn.oidc.jwks.jwks-type

Furthermore, generating and managing the JWKS resource can now be externalized and outsourced to a REST API, while the file-based JWKS strategy continues to be the default.

Other Stuff

  • Support for client_secret_basic authentication is now available for OAuth/OpenID Connect refresh token requests.
  • Handling of OpenID Connect’s max_age request parameters is now corrected.
  • Italian message bundles are now refreshed to match the latest expected language keys.
  • CAS discovery profile is now set to correctly produce output in JSON format.
  • Throttling authentication requests using Bucket4j is now corrected to consume buckets only once.

Library Upgrades

  • Spring Security
  • Twilio
  • Spring Boot
  • Hazelcast Azure
  • Pac4j
  • Hibernate
  • Person Directory
  • Apache Tomcat
  • Mockito
  • Spring
  • JUnit
  • JavaParser
  • Okio
  • Swagger
  • Oshi
  • JUnit
  • Micrometer
  • Google Authenticator
  • Amazon SDK
  • Nimbus
  • Infinispan
  • SQLServer Driver
  • PostgreSQL Driver

Credits

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

Misagh Moayyed

Related Posts

Apereo CAS is now on Develocity

An overview of how Apereo CAS is using Gradle and Develocity to improve its build and test execution cycle.

CAS OAuth/OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the Apereo CAS software acting as an OAuth/OpenID Connect provider.

CAS Groovy Vulnerability Disclosure

Disclosure of a security issue with the Apereo CAS software when using Groovy.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the Apereo CAS software acting as an OpenID Connect Provider.

CAS X.509 Vulnerability Disclosure

Disclosure of a security issue with the CAS software and its X.509 features.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.

CAS Spring Framework RCE Vulnerability Disclosure

Disclosure of the Spring framework RCE security issue with the Apereo CAS software.

CAS OpenID Connect Vulnerability Disclosure

Disclosure of a security issue with the CAS software acting as an OpenID Connect Provider.