WildFly 25 Beta1 is released!
By Brian Stansberry
| September 20, 2021
I’m pleased to announce that the new WildFly and WildFly Preview 25.0.0.Beta1 releases are available for download at https://wildfly.org/downloads.
Work during the WildFly 25 development cycle has been primarily oriented toward completing a long planned evolution of our security layer. Before diving into that topic, there are a few significant new feature areas where feedback from our users would be most welcome.
-
A new subsystem providing support for OpenTelemetry Tracing. WildFly still provides MicroProfile OpenTracing as an alternative, but I encourage users to switch to the new OpenTelemetry subsystem.
-
A new subsystem that provides native support for OpenID Connect. This allows you to do things like configure integration with a Keycloak server without needing to install the Keycloak client adapters.
-
An update of the MicroProfile Reactive Messaging subsystem to version 2.0 of the spec, along with improvements in the ability to configure Reactive Messaging Kafka messages and security integration related improvements, particularly the ability to use an SSLContext configured in the Elytron subsystem.
-
Ability to use the same expression as the value of a server configuration attribute and have it be resolvable from both a system property and an environment variable. This makes it easier to reuse configuraiton in different deployment enviroments, particularly in cloud environments where environment variables are more readily used than system properties.
Elytron all the way; removal of legacy security support
Over four years ago with the WildFly 11 release, WildFly introduced integration of the Elytron security project as its next generation security layer. From that point onward, use of Elytron has been our recommended approach to security in WildFly. However, we’ve continued to provide as well what we call "legacy security", i.e. security services that often integrate with Elytron under the covers, but which use to some degree the Picketbox security project that was the basis for security in JBoss AS and WildFly releases prior to WildFly 11. We continued to provide "legacy security" both to give our users time to shift their use to Elytron, and to give the Elytron layer time to evolve. Which it very much has, often accounting for the largest number of new features in a WildFly release!
We deprecated the use of legacy security long ago, but now with the WildFly 25 release, we are removing support for it. There are a few reasons for this:
-
The Picketbox and related Picketlink projects have not had an active community for some years now, and their project repos on Github are archived. There is no feature or enhancement work in these projects. For bug fixes WildFly has needed to rely on occasional bug fix releases produced by Red Hat for users of its Red Hat JBoss Enterprise Application Platform product.
-
Picketbox makes extensive use of Java SE packages that were pruned in SE 14. With the advent of the SE 17 LTS release, we need to eliminate use of libraries that cannot function on SE 17.
-
We feel the Elytron solution is better and that our users who have not yet migrated to it are better served by doing so.
As part of this change you will see a number of significant changes in WildFly 25 Beta1:
-
Our standard configuration files no longer include legacy security realms. These are the 'security-realm' elements found under the 'management' element in a standalone.xml or host.xml file, administered via the CLI at '/core-service=management/security-realm=*' addresses. The xml parsers no longer support these elements and the management API no longer provides resources at these addresses. Elytron subsystem resources are now used.
-
Use of the Picketbox-based security vault is no longer supported. Elytron credential stores should be used instead.
-
The 'org.wildlfy.extension.picketlink' extension and the 'picketlink-federation' and 'picketlink-idm' subsystems it provided are no longer supported on servers not running in 'admin-only' mode. They can still be used on a WildFly 25 Domain Controller to allow it to manage hosts running earlier versions of WildFly.
-
The 'org.jboss.as.security' extension and the 'security' subsystem it provides are no longer part of our standard configuration files. By the time WildFly 25.0.0.Final is released our intent is that these will no longer be supported on servers not running in 'admin-only' mode. The extension and subystem can still be used on a WildFly 25 Domain Controller to allow it to manage hosts running earlier versions of WildFly.
Note that the reason use of the legacy security and picketlink extensions is allowed on an 'admin-only' server is to allow a server with a configuration using those to boot so an administrator can then use the CLI to alter the server configuration to use Elytron.
I very much encourage any of you still using legacy security in your configuration to start experimenting with WildFly 25.
SE 17
While there are a few small issues related to running WildFly and WildFly Preview on SE 17 that we’ll sort out before WildFly 25 Final, overall it runs well and I encourage our community to try it and let us know if you have any problems.
Domain Mode and "Mixed Domains"
One aspect of WildFly’s domain mode of operation that doesn’t get a lot of attention is the ability for a Domain Controller running the latest version to manage remote Host Controllers running earlier versions. We call this a "mixed domain". Every few years we prune the number of legacy versions that a Domain Controller can support. We’re doing this with WildFly 25, restricting mixed domain support to hosts running WildFly 23 or later.
WildFly Source-to-Image (s2i) Images
The s2i image for WildFly 25.0.0.Beta1 is not yet available, but we expect it will be within a few days. When it is we’ll announce it separately.
