Apereo Community Blog

CAS 5.1.0 RC1 Feature Release

Friday, Dec 23, 2016
17 minute read

The official CAS 5.0.0 GA was released about 6 weeks ago. Since then, the project has been moving forward with development of the next feature release that is tagged as 5.1.0. This post intends to highlight some of the improvements and enhancements packed into the first release candidate in the 5.1.0 series.

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

Log Levels via CAS Properties

The configuration of CAS logging levels is traditionally done directly inside the log4j2.xml file. As an easier option and thanks to Spring Boot, log levels may also be specified via the normal CAS properties:

logging.level.org.springframework.web=DEBUG
logging.level.org.apereo.cas=DEBUG

Name Authentication Handlers

Additional CAS properties are exposed for all authentication handlers so they can individually be named. By default, handler names are set to the name of the defining Java class. Given the class name might change, it’s preferred if each adopter defines unique/custom names for each scheme.

You generally do NOT have to worry about this behavior at all; It’s only relevant if you, for instance, have defined multifactor authentication bypass rules based on authentication handler names.

JWS/JWE Compression

CAS ciphers that deal with signing/encryption based on JWEs are now by default configured to force compression via the zip claim.

Security Filters Enabled by Default

CAS has long had options to enforce a number of request headers to enable XSS/HSTS/etc protection. These filters are turned on by default, starting from this release candidate.

CORS Security Filter

Much like the above option, CAS adds support for enabling a CORS filter that should help more with CAS enabled applications which are accessed via XHR/Ajax requests. This filter is off by default and needs to be explicitly configured by the adopter.

Database AuthN BCrypt Encoder

Thanks to community contributions, minor changes are made to the internal CAS authentication API to ensure password encoding can execute correctly specially when the BCrypt encoder is defined.

Duration as Unit of Measure

Thanks to community contributions, all CAS settings that deal with time units should start to support the duration syntax for full clarity on unit of measure:

"PT20S"     -- parses as "20 seconds"
"PT15M"     -- parses as "15 minutes"
"PT10H"     -- parses as "10 hours"
"P2D"       -- parses as "2 days"
"P2DT3H4M"  -- parses as "2 days, 3 hours and 4 minutes"

Risk-Based Authentication

CAS is able to track and examine authentication requests for suspicious behavior. Risk-based authentication allows CAS to detect suspicious and seemingly-fraudulent authentication requests based on past user behavior and collected authentication events, statistics, etc. Once and after primary authentication where the principal is identified, the authentication transaction is analyzed via a number of configurable criteria and fences to determine how risky the attempt may be. The result of the evaluation step is a cumulative risk score that is then weighed against a risk threshold set by the CAS operator. In the event that the authentication attempt is considered risky well beyond the risk threshold, CAS may be allowed to take action and mitigate that risk.

You can learn more about this feature here. At this point, the changeset and accompanying modules are fairly experimental and are going through rounds of testing and patching. If this functionality interests you, by all means give it a trial run and share feedback as much as possible.

AuthN Events in Audit Log

CAS events are now routed to the CAS audit logs. This allows one, for instance, to learn when an MFA event is triggered and to note if MFA was successfully honored and executed:

=============================================================
WHO: audit:unknown
WHAT: [event=mfa-duo,timestamp=Mon Nov 14 12:01:17 MST 2016,source=RankedAuthenticationProviderWebflowEventResolver]
ACTION: AUTHENTICATION_EVENT_TRIGGERED
APPLICATION: CAS
WHEN: Mon Nov 14 12:01:17 MST 2016
CLIENT IP ADDRESS: 110.5.75.1
SERVER IP ADDRESS: 110.2.75.1
=============================================================

Duo Security Account Checking

Presently, if users are unregistered with Duo Security or allowed through via a direct bypass, CAS puts the user through multifactor authentication and simply validates the response internally and somewhat invisibly, allowing the application to receive an authentication context that indicates multifactor authentication did actually commence.

In this release, CAS starts to query the user account apriori to learn whether user is registered or configured for direct bypass. If the account status matches either of those conditions or the user account is not registered yet the new-user enrollment policy allows folks to skip registration, CAS will bypass Duo Security altogether and will NOT report back a multifactor-enabled authentication context back to the application.

Duo Security Multiple Configurations [1]

CAS is now able to support different configuration blocks for multiple Duo Security instances:

# cas.authn.mfa.duo[0].duo-secret-key=
# cas.authn.mfa.duo[0].duo-application-key=
# cas.authn.mfa.duo[0].duo-integration-key=
# cas.authn.mfa.duo[0].duo-api-host=
# cas.authn.mfa.duo[0].id=mfa-duo
...
# cas.authn.mfa.duo[1].duo-secret-key=
# cas.authn.mfa.duo[1].duo-application-key=
# cas.authn.mfa.duo[1].duo-integration-key=
# cas.authn.mfa.duo[1].duo-api-host=
# cas.authn.mfa.duo[1].id=mfa-second-duo
...

By default, a Duo Security provider in CAS is registered under mfa-duo noted by the above id. However, additional providers can now be registered with arbitrary identifiers. All MFA triggers shall function exactly as before and as long as they are configured to produce the right match for the right provider id, CAS will activate MFA for the Duo Security configuration that is linked to the selected identifier.

At this point in time, Duo Security is the only provider in CAS whose configuration can be specified in blocks. However, [and this turned out to be a VERY non-trivial task], adjustments are made internally to ensure other providers can be configured in much the same way should there be demands.

Embedded Container Version

The embedded container version now shows up in the CAS banner on startup:

CAS Version: 5.1.0-SNAPSHOT
...
Container Version: Apache Tomcat/8.5.x

Redis Ticket Registry

Thanks to community contributions, CAS gains support for Redis as a storage machenism for its ticket registry backend. Redis is an open source in-memory data structure store, used as a database, cache and message broker. You can learn more about the registry behavior via this guide.

Code Cleanup and Optimization

Thanks to community contributions, the CAS codebase is revitalized ever more to make sure most if not all underlying components adhere to proper coding standards and design practices. Changes in this area include adjustments to style guidelines, constructor-based dependency injections and navigating from Guava Collections to the native Java 8 Collections/Lambda APIs.

Registered Service Legacy Definitions

Thanks to community contributions, CAS’ handling of legacy service registry definitions that are backed by JSON are now slightly improved to preserve backwards compatibility with prior CAS versions whose service definition was based on the old org.jasig namespace.

LDAP Search Filter Parametrization

A number of LDAP search filters for SPNEGO and attribute repository configurations are relaxed to be more consistent with other parameter names via supporting both {user} and {0} for both named and index parameter values.

LDAP Connection Strategies

Additional configuration options are now made available to allow users to define a connection strategy of their own choosing, should multiple LDAP urls be specified in the configuration.

MongoDb Authentication: Password Encoding

Minor bug fix; Improper construction of password encoders caused MongoDb authentication attempts to reject all user credentials, failing to apply proper hashing/encoding on the password for validation. This should now be fixed.

Service Registry Performance

Thanks to community contributions, there have been a number of performance improvement applied to the way CAS saves, updates and locates services internally. Likewise, improvements are applied to the way CAS services handle regex pattern matching when responding to requests.

LDAP Principal Attributes Merged with Attribute Repositories

LDAP authentication in CAS can be made to directly resolve attributes without involving external attribute repositories via Person Directory. While simple, this isn’t always the use case. For instance, if there is ever a requirement to additionally resolve attributes from a JDBC source, the adopter is to abandon attribute resolution directly as part of LDAP authentication and is then forced to define a separate LDAP attribute repository source alongside a JDBC source so the final result from both can be merged.

This is now improved such that attributes retrieved as part of LDAP authentication are now merged with all other attributes retrieved from attribute repository sources, if any.

Internal Auto Configuration [1]

CAS 5 took the auto-configuration strategy to the next level, thanks to Spring Boot and Spring Cloud. The approach was to component-scan the application context under org.apereo.cas and load components and beans that were declared via the housing @Configurations.

In this release, CAS entirely turns off component scanning and switches to Spring Boot’s auto-configure style. The strategy is more or less the same where @Configuration classes still register CAS components as @Beans. The difference is that each CAS module provides a spring.factories file in which configuration classes and application context initializers are placed. This strategy allows CAS to exactly control the set of configurations that are loaded very explicitly for each mdule and also helps with deterministic load behavior where configurations for instance can register themselves to be loaded before or after a particular component to accommodate runtime behavioral dependencies.

This may partially help with start-up times as well when CAS is run via the embedded container, but so far tests show that performance more or less remains the same.

Note that while this isn’t generally something that the average adopter needs to worry about, this is nonetheless a breaking change IIF you have designed Java components/classes that are auto-scanned under org.apereo.cas. Those will NO LONGER be picked up by CAS automatically and you will need to either manually register them as CAS does via your own spring.factories or set up a auto-scanning configuration under your own package names via @ComponentScan, etc.

Multiple Attribute Repositories [1]

Attribute repository sources that are controlled and managed via Person Directory have now turned into lists. This allows you to create more than one source if necessary and then have all sources be merged into a single repository automatically to resolve CAS principals and attributes.

# cas.authn.attribute-repository.ldap[0].ldap-url=ldaps://ldap1.example.edu,...
...
# cas.authn.attribute-repository.ldap[1].ldap-url=ldaps://ldap2.example.edu,...
...

Attribute Repositories Order

You have to consider that when you have more than one attribute repository source defined, there may be cases where two sources end up colliding as they both may produce the same attribute. In such cases, CAS already provides capabilities to merge the final result and take action to either add, replace or ignore subsequent attempts at producing an attribute, if one already is found and fixed. This becomes important as it directly impacts the execution order of sources.

For instance, consider that you have sources S1 and S2 defined both of which are configured to produce an attribute A1. Policies are configured to note that if A1 is already found via one source, no other source should attempt to overwrite it. The question then really becomes: which source should execute and query for data first?

To handle this, CAS allows you to order attribute repositories. Those with a lower order execute first and take priority in querying for attributes:

# cas.authn.attribute-repository.ldap[0].ldap-url=ldaps://ldap1.example.edu,...
# cas.authn.attribute-repository.ldap[0].order=1
...
# cas.authn.attribute-repository.ldap[1].ldap-url=ldaps://ldap2.example.edu,...
# cas.authn.attribute-repository.ldap[1].order=10
...

Service UI Info on Login Screen

In situations where CAS ends up playing proxy behind a protocol such as SAML2, OAuth or OIDC, the login screen wrongly displayed the UI metadata (i.e. logo, description, etc) about the proxying (callback) service. This is now corrected so relevant UI information about the real service/destination is displayed on the screen per the SAML metadata or the CAS service registry.

SAML2 ECP

CAS starts to support a rather modest implementation of the SAML2 ECP profile. At this point, the changeset and accompanying modules are fairly experimental and are going through rounds of testing and patching. If this functionality interests you, by all means give it a trial run and share feedback as much as possible.

SAML2 InCommon Metadata

A number of improvements are applied to the way CAS handles the retrieval and resolution of large SAML metadata files that are downloaded over the web. The download strategy is now handled over a multi-part multi-threaded connection which should boost performance and startup times quite a bit.

InCommon SPs are now supported directly via the usual CAS configuration settings, while in the past adopters expicitly had to register InCommon in the CAS service registry.

SAML2/OAuth/OIDC Multifactor Authentication

CAS triggers for multifactor authentication have all been reorganized in much the same way as the above item to ensure that authentication requests via SAML2, OAuth or OpenID Connect may all go through multifactor authentication based on the real service and not the proxying (callback) url.

SAML2 IdP Metadata Signature Validation

Metadata signature validation can now be done both via public keys and certificate files.

SAML2 IdP Metadata Location URI

A trivial bug fix; the location of the metadata for CAS’ SAML2 IdP functionality can now be specified in URI format as well. (i.e. file://etc/cas/somewhere)

Service Registry JSON Auto-Init

Service registries can now take advantage of the auto-initialization feature in a more direct manner. The previous behavior only populated a given registry if it was left empty by the adopter. However, in certain cases CAS modules auto-insert service definitions into the registry and interfere with this auto-initialization behavior. This is now corrected to ensure the service registry, if permitted, can forcefully be populated regardless of size while gracefully ignoring duplicate entries that may already be present.

Embedded Container HTTP2 Support

The embedded container is now configured to automatically upgrade the protocol and support HTTP2. Note that activation of this feature for an external Apache Tomcat instance requires Apache Tomcat 8.5.6 or above.

Internet2 Grouper MFA Trigger

As an extra option, CAS can now integrate with Grouper and use a subject [CAS principal] groups’ to learn whether MFA should be triggered. As an example, you could devise a use case where all subjects who are assigned to an mfa-duo groups may be asked to execute MFA via Duo Security. If you have deployed Grouper, this may be a much more immediate option than to pick up changes based on a given principal attribute once after provisioning has had a chance to process.

REST API Performance

Thanks to community contributions, improvements have gone into the implementation of CAS REST APIs to ensure best coding practices are in-place, performance-wise.

LDAP Validator Configuration

Additional properties are now exposed to allow configuration of LDAP validators for ALL operations that deal with LDAP functionality. CAS supports both SEARCH and COMPARE modes.

Logging Panel

CAS provides an administrative screen to manage and review logs. This screen is now improved to allow one to update logger levels immediately from the UI and observe better CAS diagnostics data.

image

Note that at present, changes applied to the configuration UI are only persisted in memory since the underlying framework does not yet provide a way to save changes back out to disk, etc. This means, once you restart the CAS server node all changes applied to logs via the configuration panel are lost.

Improved Hazelcast Configuration

Minor adjustments are made to the Hazelcast configuration to stop using deprecated settings for internal eviction policies.

SAML2 IdP Handling of RelayState

Thanks to community contributions, the SAML2 functionality of CAS is now able to properly retain the RelayState parameter.

JSON Enhancements to CAS APIs

Thanks to community contributions, CAS APIs are now slightly massaged to handle JSON serialization of core ticketing components. This is useful for ticket registry implementations that are based on NoSQL databases such as Apache Cassandra, which as a pending pull request may also soon become a first-class CAS ticket registry feature.

Multifactor Authentication Bypass Per Service

In this release CAS starts to provide options to selectively exclude a set of applications from multifactor authentication. This is useful in cases where you have turned on multifactor authentication globally. A number of other bugs also in this area have been fixed to ensure handler/authentication attribute names can correctly be defined to bypass multifactor authentication.

OIDC Delegated AuthN Scope

Having upgraded to early snapshots of Pac4J, additional CAS configurtion options are now made available to allow for providing scope when delegating authentication to an external OIDC provider.

LinkedIn Delegated AuthN

Thanks to the early Pac4J upgrade, CAS now starts to support delegating authentication to LinkedIn in addition to a variety of other social providers.

Management Webapp Authorization Roles [1]

The authorization roles for the management webapp and the administrative user interfaces are now modified to allow distinct roles for access without the need for extra data parsing:

# cas.adminPagesSecurity.adminRoles[0]=ROLE_ADMIN
...
# cas.mgmt.adminRoles[0]=ROLE_ADMIN
# cas.mgmt.adminRoles[1]=ROLE_SUPER_USER

OIDC Dynamic Client Registration

OpenId Connect in CAS is now starting to support modest implementations of the dynamic client registration protocol.

JWTs as Service Tickets

Starting with this release candidate, CAS gains the ability to issue JWTs as service tickets. JWTs are entirely self-contained and include enough information about the authenticated principal and available claims for given application integration.

Delegated AuthN Auto Redirect

In the event that you have configured CAS to delegate authentication to an external [social] identity provider, options are now made available to automatically redirect the authentication flow to the provider bypassing the CAS login screen. This option today is only relevant and active if there is a single provider available.

Library Upgrades

  • Spring
  • Spring Boot
  • Spring Cloud
  • Spring Security
  • Thymeleaf
  • Commons Lang
  • Guava
  • Pac4J
  • Ldaptive
  • MongoDb
  • OpenSAML
  • FindBugs
  • Checkstyle
  • Joda Time
  • Couchbase
  • Hibernate
  • MySQL, MaridaDb and PostgreSQL Drivers
  • Kryo

What’s Next?

The development team is working to make sure the CAS 5.1.0 release is on schedule. Additional release candidates and more updates will likely be released prior to the official GA release.

Get Involved

  • Start your CAS deployment today. Try out features and share feedback.
  • Better yet, contribute patches.
  • Review and suggest documentation improvements.
  • Review the release schedule and make sure you report your desired feature requests on the project’s issue tracker.

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

  • [1] This is a breaking configuration change. Please consult the CAS docs to learn more.

Follow Apereo on Twitter.

Related Posts

CAS OAuth/OpenID Connect Vulnerability Disclosure

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

CAS OAuth/OpenID Connect Vulnerability Disclosure

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

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.