CAS 5.1.0 RC3 Feature Release

The official CAS 5.0.0 GA was released on November 7th 2016. 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 third 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.

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

• Embedded Container Modules
• Hazelcast Ticket Registry
• Embedded Tomcat SSL Valve
• Administrative Endpoint Security
• Scripted Username Attribute Providers
• SPNEGO Webflow Authentication
• JPA Ticket Registry
• Ticket Metadata and Catalog
• Embedded Tomcat Default Connector Settings
• Code Cleanup and Optimization
• Configuration Panel
• Spring Cloud Configuration Server
• DynamoDb Ticket Registry
• CAS Heroku Demos
• Attribute Repositories & Attributes
• AWS CloudWatch Support
• Sass Auto Compilation
• REST Authentication via X.509
• X.509 Principal Resolution
• WS-Fed Protocol
• Attribute Filtering Policies
• Jasypt Support
• DynamoDb Service Registry
• Minor Bug Fixes
  • Community Contributions
  • Others
• Library Upgrades
• What’s Next?
• Get Involved
• Das Ende

Embedded Container Modules

In previous feature releases, the CAS server web application module shipped automatically with an embedded Tomcat container. This presented a few difficulties to folks who wanted to step outside the box and get the CAS web application deployed in alternative containers such as WebSphere, JBoss, etc.

Starting with this release candidate, the CAS server web application switches back to its original vanilla state where nothing is embedded by default. This should allow you to deploy CAS to any container that is servlet-spec compliant by CAS requirements. However, additional modules are provided for embedded containers that are Apache Tomcat, Jetty and Undertow. If you had been previously working with the embedded container and running Apache Tomcat natively, you do need to switch the webapp module to one that contains an embedded container of your choice.

Note that embedded-container modules may be deployed to externally-configured containers too. CAS should detect the external instance and auto-disable the embedded container from bootstrapping itself, regardless of container type.

Hazelcast Ticket Registry

Thanks to community contributions, the Hazelcast Ticket Registry is reorganized to improve its performance, by splitting the underlying cache in half. Work is also done to ensure the registry is prepped to handle additional ticket types dynamically.

Embedded Tomcat SSL Valve

Thanks to community contributions, the embedded tomcat container gains support for configuration of the SSL Valve. This should be useful if you are trying to handle X.509 authentication at the servlet container level.

Administrative Endpoint Security

Individual endpoints that are exposed by the CAS admin panels each have their own security settings. To make the configuration easier, there now exists a single block that may control the security of all settings globally, while still allowing individual overrides to take over.

As an additional option, endpoints that are secured with Spring Security now can take advantage of JAAS authentication.

Scripted Username Attribute Providers

Username attribute providers linked to a service definition are enhanced to accommodate further scripting techniques via Groovy. Also, a number of providers are now able to apply transformations on the final username returned back to the application, such as turning the id into all caps, etc.

SPNEGO Webflow Authentication

The SPNEGO functionality still had a few references and instructions on how changes that needed to be manually applied to the webflow. Those are now removed and automated internally to match the manual steps.

JPA Ticket Registry

The JPA ticket registry no longer requests a hardcoded dependency link to the OAuth module. In the past, the registry simply auto-created OAuth tables and entities given the components were found and scanned automatically as a result of that dependency link. Today, that chain is removed and the registry shall only recognize and act upon OAuth functionality, if the functionality is explicitly turned on.

Ticket Metadata and Catalog

Traditionally, ticket types in CAS are mostly concerned with ticket-granting tickets, service tickets, proxy tickets, etc. These are distinct types that are defined as first-class citizens of the CAS public API. Over time, there have emerged additional tickets types that represent various other forms of tokens to CAS, such as OAuth codes, access tokens, refresh tokens, etc. Each ticket type has its own lifespan and other settings too. How do ticket registries deal with additional types, given their presence and functionality can only be discovered at runtime dynamically?

Some took shortcuts. For instance, the JPA ticket registry created a hard-link to the OAuth module (described above) so it could ensure OAuth tickets were stored in separate tables as distinct entities, etc. It asked for pre-authorized knowledge of the CAS API, even though the functionality controlled by that API may not even be in use at all. Is there a reason the registry should handle OAuth-related functionality even when OAuth is not even enabled or required by the deployment?

Not a trick question.

So the target goal is that each registry implementation (and all of CAS really) should be able to dynamically realize what ticket types are used by the CAS runtime and what ticketing-related functionality is actually enabled by the deployer. The discovery mechanism should provide enough information, as a catalog, to the relevant modules about known types, their metadata and various other required properties so each registry can dynamically and generically look up that metadata and regroup itself to handle each unique type. Advantages of this approach are:

1. No need to establish static linkage between CAS modules to teach each about various ticket types exposed in the module API. As you can imagine, over time given new tickets types that have emerged and the list of registries supported by CAS, static linking is simply non-maintainable and core logic in each registry can get very messy if it were to deal with 8+ different ticket types, caches, storage requirements, etc.
2. Given no static linking, LOC will be reduced down to the bare minimum and what may be auto-discovered at runtime.
3. Given no static linking, maintenance and extensions to the CAS API can be done much more comfortably.
4. Given no static linking, the amount of extra [yet needless] work that would be carried out by each registry is only activated IIF the feature is actually utilized by the deployment.

So starting with this release candidate, modules that intend to provide their own special flavors of tickets when necessary register the relevant types into the “global ticket catalog” as it were. Registries are then freed up look into the catalog and reorganize themselves as needed to handle all ticket types.

Embedded Tomcat Default Connector Settings

In the event that you decide to run CAS without any SSL configuration in proxying mode and perhaps on a non-secure port, there are now additional settings exposed in the configuration that allow you to control the behavior of the connector linked to the port, to mark it as secure with a scheme of https, etc.

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 better adherence to the native Java 8 Collections and Lambda APIs.

Configuration Panel

A number of enhancements are applied to the CAS configuration panel to ensure it can detect properties that are changed manually in configuration sources (i.e cas|application.properties). The panel is also able to now immediately apply configuration changes. This item is closely related to the changes done, described below, to externalize the deployment of the Spring Cloud Configuration Server.

Spring Cloud Configuration Server

In previous versions and release candidates, CAS shipped with an embedded configuration server backed by Spring Cloud. While extremely powerful, this added a number of complications such as bootstrap start-up times and extra care around securing various endpoints, etc. In this release candidate, the configuration server functionality is pulled out of the main CAS server web application and is produced as a separate project with its own overlay. Deployments may choose to run CAS in a standalone mode or they may wish to let CAS become a client of the centralized configuration server consuming settings from multiple sources for a variety of profiles, etc.

Note that if you’d deployed CAS with the understanding of reading configuration files from the default /etc/cas/config, then you should have very little, if anything, to worry about if and when you make the jump. If you have deviated from the defaults and decided to go your own way, please consult the documentation to learn about needed readjustments.

DynamoDb Ticket Registry

CAS gains support for DynamoDb as yet another option for its ticket registry. This feature might look more attractive for those who wish to use AWS as the deployment environment and take advantage of native platform services and offerings.

CAS Heroku Demos

Demo instances of both the CAS server and CAS Management server web applications have been updated to run the latest versions of CAS 5.

Attribute Repositories & Attributes

A requested improvement from the 5.0.x days; Deployments that cannot not rely on the attribute retrieval mechanism done during the same authentication request/transaction typically use separate attribute repositories to define retrieval rules. This allows one to for instance say:

Authenticate against a JDBC source, but retrieve attributes from separate LDAP and Groovy sources.

Or a bit more advanced:

Authenticate against an LDAP source, but retrieve attributes from multiple LDAP repositories yet map attributes for each differently depending on the authentication source.

So long story short, attributes that were to be retrieved from such sources were all defined in one common block global to all repositories. In this release, the attributes are removed from the global common block in CAS configuration settings and made specific for each attribute repository instance that is defined. This provides a much more flexible configuration where one could for instance then say:

Authenticate against a JDBC source, but define two LDAP sources for attributes where one is only allowed to request/retrieve attributes A,B,C while the other can only request/retrieve X,Y,C. Oh…map these attributes for each source differently. Then merge it all together and resolve conflicts. Have fun while doing it!

Fun times.

AWS CloudWatch Support

CAS gains support to route logs automatically to AWS CloudWatch. You can review this guide here to learn more. You are also allowed to use other logging and monitoring tools such as Sentry, Syslog and Logstash to manage and route CAS logs in addition to all the usual options.

Sass Auto Compilation

Sass files are now automatically and as part of the build compiled to .css files for the main CAS server web application.

REST Authentication via X.509

CAS REST Protocol gains the ability to authenticate credentials via X.509, thanks to community contributions.

X.509 Principal Resolution

Thanks to community contributions, X.509 principal resolution by serial number is now able to support HEX and other configurable radixes.

WS-Fed Protocol

Starting with this release candidate, CAS gains modest support for the WS-Fed protocol, acting both as an identity provider and security token service.

Attribute Filtering Policies

A number of new attribute filters are worked into this release that provide support for selectively applying patterns to attributes values to allow or disallow them.

Jasypt Support

Running CAS in standalone mode now allows you the option to place encrypted settings into the CAS configuration files and then have them be decoded automatically. This feature is brought to you by CAS taking advantage of Jasypt.

DynamoDb Service Registry

CAS gains support for DynamoDb as yet another option for its service registry. This feature might look more attractive for those who wish to use AWS as the deployment environment and take advantage of native platform services and offerings.

Minor Bug Fixes

A number of small bug fixes have been incorporated into this feature release:

Community Contributions

• SAML2 InResponseTo field is now correctly set in response.
• JDBC data sources are massaged to correctly handle the minimum number of idle connections.
• YAML properties are now correctly loaded both from the embedded web application as well as externalized sources.
• Regressions that made service properties in the CAS management webapp dysfunctional are now removed/fixed.
• LDAP authentication removes the need for separate SASL authentication type option, folding it neatly into AUTHENTICATED.
• Documentation improvements to explain the proper encoding used for .properties and .yml files.

Others

• OAuth services are now properly recognized during the logout process.
• SAML2 authenication statements should now properly include a session index.
• CAS cookies are set to httpOnly by default with options to control this behavior externally.
• SAML2 attribute statements should now correctly use the SAML2 prefix when constructing attribute values.
• SAML2 ECP functionality gets a brand new pass to resolve a series of issues with encodings and responses.

Library Upgrades

• Spring
• Hazelcast
• Spring Boot
• Apache Tomcat
• Spring Cloud
• Hibernate
• Log4j
• HJSON
• Metrics
• Groovy
• JodaTime
• …

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