Skip navigation
2019

This blog post highlights the new security features included in WildFly 18.

 

Certificate Authority Configuration

 

Since WildFly 14, it's possible to obtain and manage certificates from Let’s Encrypt using the WildFly CLI. WildFly 18 now adds the ability to make use of any certificate authority that implements the Automatic Certificate Management Environment (ACME) protocol. More details can be found in this blog post.

 

Simplified SSL Configuration with Let’s Encrypt

 

It is now possible to use the ssl enable-ssl-management and enable-ssl-http-server commands to easily enable one-way and two-way SSL using certificates obtained automatically from Let’s Encrypt. Details on how to get started with these commands can be found here.

 

SSL Certificate Revocation Checking using OCSP

 

Certificate revocation checks can now be performed using the Online Certificate Status Protocol (OCSP) in addition to certificate revocation lists (CRL). Details on how to configure an Elytron trust manager to perform certificate revocation checks can be found here.

 

Enhanced X509Certificate Identity Mapping

 

Prior to WildFly 18, the mapping of an X.509 certificate chain to an identity was done by taking the subject distinguished name from the first certificate in the X.509 certificate chain as an X.500 principal. It is now possible to map an X.509 certificate chain to an identity by using a subject alternative name from the first certificate in the X.509 certificate chain. For a complete overview of this feature, take a look at this blog post.

 

Identity Attribute Aggregation

 

Elytron already had a very flexible approach for assigning roles and permissions to an identity based on arbitrary attributes loaded by a security realm. This feature adds support for loading the attributes from multiple security realms and aggregating the results together. Check out this blog post for more details on this feature.

 

Aggregate Realm Principal Transformer Configuration

 

It is now possible to configure a principal transformer for an aggregate realm that will be used to transform the principal after the authentication identity is obtained but before the authorization identity is obtained. A complete example on how to configure and make use of this principal transformer can be found here.

 

Enhanced Audit Logging

 

Support for both RFC 5424 and RFC 3164 have now been added to Elytron’s audit logging capabilities as well as the ability to configure how many times Elytron should attempt to send messages to a syslog server when an error is encountered during sending. More details on this feature can be found here.

 

Masked Password Support

 

It is now possible to specify masked passwords when using the Elytron Authentication Client. Check out this blog post for examples on how to make use of masked passwords.

 

Where to Find More Information

 

As always, be sure to check out our blog posts page, where we collect references to all our blog posts on Elytron features. If there is an Elytron topic you’d like to see a blog post on, feel free to leave a comment on that page to ask for it. Questions on Elytron are also welcome on WildFly’s user forums.

 

To learn more about the Elytron subsystem, take a look at the Elytron documentation.

One of the new security features that we have been working on is adding support for automatic updates of credential stores. Although this feature didn’t make it into WildFly 18, the plan is to have it included in WildFly 19. This blog post will give an introduction to this new feature.

 

Credential References

 

A credential store allows for secure storage of credentials. It is possible to populate and manipulate a credential store using the WildFly CLI. Once a credential has been added to a credential store, it is possible to reference the stored credential. In particular, many resources across WildFly’s management model support a credential-reference attribute that can be used either to specify a clear-text password or to cross-reference a credential from a configured credential store. As an example, when configuring a key-store in the Elytron subsystem, a credential-reference is used to specify the credential that should be used to access the keystore. This can be configured as follows:

 

First, let's configure a credential-store (note that the mycredstore.cs file doesn’t need to exist yet):

 

/subsystem=elytron/credential-store=myCredStore:add(location=mycredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)

 

Next, we'll add a credential to our credential-store:

 

/subsystem=elytron/credential-store=myCredStore:add-alias(alias=example, secret-value=mySecretPassword)

 

Finally, we can configure a key-store and reference this newly added credential:

 

/subsystem=elytron/key-store=myKS:add(relative-to=jboss.server.config.dir, path=my.keystore, type=JCEKS, credential-reference={store=myCredStore, alias=example})

 

Notice that the credential-reference has two attributes, store and alias. The store attribute indicates the credential store. The alias attribute indicates the entry in the credential store that holds our credential.

 

Automatic Updates

 

Instead of needing to first add a credential to a configured credential store in order to reference it from a credential-reference, WildFly 19 will add the ability to automatically add a credential to a previously defined credential store by specifying both the store and clear-text attributes for a credential-reference. In particular, when configuring a new credential-reference with both the store and clear-text attributes specified, the following will happen:

 

  • If the alias attribute is also specified, one of the following will occur:
    • If the configured credential store does not contain an entry for the given alias, a new entry will be added to the credential store to hold the clear text password that was specified. The clear-text attribute will then be removed from the management model.
    • If the credential store does contain an entry for the given alias, the existing credential will be replaced with the clear text password that was specified. The clear-text attribute will then be removed from the management model.
  • If the alias attribute is not specified, an alias will be generated and a new entry will be added to the credential store to hold the clear text password that was specified. The clear-text attribute will then be removed from the management model.

 

As an example, let’s configure another credential-store in the Elytron subsystem:

 

/subsystem=elytron/credential-store=myNewCredStore:add(location=mynewcredstore.cs, relative-to=jboss.server.config.dir, credential-reference={clear-text=StorePassword}, create=true)

 

Now, going back to our keystore example, from WildFly 19, it will be possible to configure a key-store with a credential-reference that specifies the store, alias, and clear-text attributes as follows:

 

/subsystem=elytron/key-store=newKS:add(relative-to=jboss.server.config.dir, path=new.keystore, type=JCEKS, credential-reference={store=myNewCredStore, alias=myNewAlias, clear-text=myNewPassword})
{
    "outcome" => "success",
    "result" => {"credential-store-update" => {
        "status" => "new-entry-added",
        "new-alias" => "myNewAlias"
    }}
}

 

The above command will result in a new entry being added to our credential store, myNewCredStore, with alias myNewAlias and credential myNewPassword.

 

When updating an existing credential-reference attribute that contains both the alias and store attributes to also specify the clear-text attribute, the existing credential in the configured credential store will be replaced with the clear text password that was specified. The clear-text attribute will then be removed from the management model. As an example, the following command will result in updating the credential for the myNewAlias entry that was just added to our credential store:

 

/subsystem=elytron/key-store=newKS:write-attribute(name=credential-reference.clear-text,value=myUpdatedPassword)
{
    "outcome" => "success",
    "result" => {"credential-store-update" => {"status" => "existing-entry-updated"}},
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

 

Summary

 

This blog post has given an introduction to the upcoming support for automatic updates of credential stores.

 

For more details on this feature and updates on the status of this feature, keep an eye on WFCORE-4150.