Security Features for WildFly 17

The development for WildFly 17 has now commenced, here are some of the features we are planning to be looking into developing for WildFly 17.

WFCORE-4360 Support encrypted expression resolution using a CredentialStore

The previous Vault implementation was effectively a repository of encrypted clear text strings that could be referenced using expressions in the management model, the new CredentialStore is a repository of credentials.  WFCORE-4360 is to look into how the CredentialStore could be used to support encrypted values within the overall model.

WFCORE-3947 Support SSL Certificate revocation using OCSP

ELY-1712 Enhanced Audit Logging

As the WildFly Elytron project was integrated with WildFly 11 an initial set of events were made available with a couple of options for logging these events, this feature request is to look into how we can enhance this further.

WFCORE-4361 Enhanced mapping of X509Certificate to the underlying identity.

Presently WildFly Elytron provides a variety of options to configure certificate based authentication, this feature request is to enhance how the certificate is mapped to the underlying identity.

WFLY-11697 Web Services Integration with WildFly Elytron

The WildFly Elytron integration added a new API and configuration file to configure the client side security for outgoing calls, this feature request is to increase the integration for web services clients.

WFCORE-4172 Add support for TLS 1.3

WFCORE-4362 Make the certificate authority used by a certificate-authority-account configurable.

At the moment integration with Lets Encrypt is supported, once the certificate authority account is configurable it will be possible to use this integration with other certificate authorities that implement the ACME protocol.

WFCORE-3832 Support hex encoding in jdbc-realm for elytron.

Using multiple security realms.
WildFly Elytron already supports the use of multiple security realms where a realm can be selected either from the authentication mechanism in use or by some recognisable pattern in the username. 

Where LoginModules were used in the previous PicketBox solution it was possible to stack the LoginModules for a few additional scenarios: -

• Failover in the event of unavailability.
• Aggregation of multiple identity stores into one.
• Allowing identities to be located in different stores.
• Allowing attributes to be loaded from multiple locations.

Issues will be created as needed to track these different scenarios but the aim is during WildFly 17 to begin to address these as they have been identified as making it difficult to migrate from PicketBox.


Also in preparation to develop WildFly Elytron 1.9 the project has been broken up into smaller modules to allow dependencies to be defined on specific modules without depending on the whole project - WildFly 17 will be switching to use the new modules.

Please keep in mind this blog post is a summary of our general plans and not a guarantee that all will be merged but it should give an indication as to the teams current priorities.  If any of these features are a priority to you please let us know, also let us know if there are missing security features you would like prioritising - we can take this into account for future releases.

WildFly Elytron 1.0.0.Alpha3 Released

At the end of last week we released WildFly Elytron 1.0.0.Alpha3

http://repo1.maven.org/maven2/org/wildfly/security/wildfly-elytron/1.0.0.Alpha3/

WildFly Elytron will be providing both SASL and HTTP authentication mechanisms for use within the application server, where possible stronger authentication mechanisms will be preferred over weaker mechanisms - there are challenges in achieving this but our ideal situation is to have no re-usable password representations transmitted over the network and also no passwords stored in reversible format on the local file system.

The 1.0.0.Alpha3 release has primarily been focussed on adding capabilities to the project to enable administrators to define policies to use when selecting SASL mechanisms and also some custom settings for when a mechanism is actually created.

• Ability to specify protocol passed into the mechanism.
• Ability to specify server-name passed into the mechanism.
• Definition of properties to pass into mechanism for available mechanism evaluation and mechanism creation.
• Filtering of mechanisms by name.
• Filtering of mechanisms by name and provider.
• Mechanism loading from a Provider[]
• Service loader based mechanism loading from a provided ClassLoader.
• Mechanism filtering based on supported credentials.

For the final item in that list at it's core the APIs that are being developers within WildFly Elytron are to enable a closer integration between the repositories that hold identity information and the authentication mechanisms.  A SecurityRealm is essentially the API used to interact with the repository of identities, from this we also obtain a RealmIdentity to represent an individual identity: -

As you can see from the above example both of these interfaces have a getCredentialSupport method, this method allows us to verify which credential types are supported in different situations and subsequently the mechanism filtering added in this release allows us to tailor the available authentication mechanisms to those actually compatible with the underlying realms.

In addition to the work on SASL based mechanisms selection the following Jira issues have also been resolved this release.

Release Notes - WildFly Elytron - Version 1.0.0.Alpha3

• [ELY-247] - NullPointerException in SecurityProviderSaslServerFactory (Not all providers return services)
• [ELY-227] - Add attribute mapping to Jdbc Security Realm
• [ELY-175] - SASL mechanism availability should take into account credential support.
• [ELY-189] - Support One-Time-Password SASL Mechanism
• [ELY-197] - Add mechanism selection policies to the security domains.
• [ELY-237] - Make it possible to configure the realm used on the client
• [ELY-238] - Recognise realm callback on digest server, and make authorize callback come last
• [ELY-239] - Make Anonumous auth set the anonymous principal name
• [ELY-242] - Delegating SaslServerFactory supporting properties
• [ELY-250] - Release WildFly Elytron 1.0.0.Alpha3
• [ELY-33] - Identity Loading
• [ELY-198] - Allow the association of Provider[] with a security domain and add support for mechanism loading.
• [ELY-219] - Process subject roles in JaasAuthorizationIdentity
• [ELY-223] - Add tests for the filesystem-backed realm
• [ELY-244] - The properties map in the sasl factories should be Map<String, ?> not Map<String, Object>
• [ELY-246] - Add github references to the pom

Next Release

The next release will be 1.0.0.Alpha4, the main feature to be included in that release will be the new APIs for HTTP authentication and an equivalent set of mechanism selection policies to allow an administrator control over HTTP authentication for their application server.