Posts

Enhanced Audit Logging in WildFly Elytron - RFC Support and Reliabiliity/Speed Customization Update

rfc_support_reliability_customization_final Enhancing Audit Logging in WildFly Elytron - RFC Support and Configuring Reconnects Update Overview In WildFly 18, audit logging in WildFly Elytron has now been enhanced with additional audit logging capabilities, with additional RFC Support and the ability to configure how many times Elytron should attempt to send messages to a syslog server when an error sending is encountered. This blog post will give an overview about the enhancements that have been added and some examples on how to use these new enhancements. Some sections of this blog post have already been detailed in the original blog post detailing the enhancements that were being worked on, available at: https://justinwildfly.blogspot.com/2019/06/enhanced-audit-logging-in-wildfly.html Additional RFC Support RFC Formats WildFly Elytron’s syslog audit logging currently only supports RFC 5424, but some users may wish to use the legacy RFC 3164. Elytron

Enhanced Audit Logging in WildFly Elytron - RFC Support and Reliabiliity/Speed Customization

rfc_support_reliability_customization Overview WildFly Elytron is currently having its audit logging capabilities enhanced. In this blog post, I will give an overview about the enhancements being added in regards to additional RFC Support and the ability to configure how many times Elytron should attempt to connect to a syslog server. Additional RFC Support RFC Formats WildFly Elytron’s syslog audit logging currently only supports RFC 5424, but some users may wish to use the legacy RFC 3164. Elytron is now being enhanced to provide support for this additional RFC through the addition of a syslog-format parameter. This new parameter will default to the current supported value of RFC 5424 and will support the value of RFC 3164, or can be explicitly set as RFC 5424. The parameter can be used on the WildFly CLI in the following ways: /subsystem=elytron/syslog-audit-log=syslog-test:add(server-address="127.0.0.1",port=10999,transport=UDP,host-name

Converting Legacy Properties Files into a FileSystemRealm with Elytron Tool

converting-legacy-properties-files-into-a-filesystemrealm Overview In WildFly 16, Elytron Tool now provides a command for easily converting any legacy properties files into a FileSystemRealm. This blog post will give an overview of the two ways parameters can be specified for this command, the various parameters, and an example of how to convert both properties files for both a single users-roles mapping and for specifying multiple files at once. The Two Ways to Specify Parameters This new command, FileSystemRealmCommand, allows the ability to specify the input files and Elytron object names on either the command line, ideal for a single users-roles combination, or through a text file called a Descriptor File, ideal for multiple users-roles combinations. In either case, the general use options will have to be specified on the command line, which are: --help --debug --silent --summary Both the command line and descriptor file have three required par

Dynamically Generating KeyStores, TrustStores, and Certificates with WildFly Elytron

dynamically-generating-certificates-keystores-in-elytron Dynamically Generating KeyStores, TrustStores, and Certificates with WildFly Elytron Overview It is now possible to quickly and easily generate KeyStores, TrustStores, and Certificates by utilizing the Elytron Examples methods. A new utility class, CertificateGenerator, has been added that can generate a KeyStore and TrustStore, along with saving them to a file-system directory, with a single API call. This utility class can further be used to easily generate client and server KeyStores and TrustStores for Two Way SSL or can be easily fully customized to create as many KeyStores, TrustStores, Certificates (self signed and signed) as wanted, along with saving as many of those KeyStores and TrustStores to as many or as few directories as wanted. This blog post will go into several of the customization and default methods available, along with showing an example. Further examples can be found in the Certi

Reinitializing a Trust Manager through a Two-Way SSL

In WildFly 14, you are able to dynamically reload trust managers using the Elytron subsystem, for trust managers using one of multiple of file and LDAP backed keystores. This blog post will give an overview of how to use this new operation through an example in the WildFly CLI. Pre-requirements Before any of the following operations can be done in the CLI, the keystores will first have to be created. As mentioned, these can either be file or LDAP backed keystores. In the following examples, the keystores will be stored in WildFly's standalone/configuration directory. File Backed Keystores First, generate the client and server keystores: keytool -genkeypair - alias client -keyalg RSA -keysize 1024 -validity 365 -keystore client.keystore.jks -dname cn=client,ou=Users,dc=jboss,dc=org -keypass secret -storepass secret; keytool -genkeypair - alias server -keyalg RSA -keysize 1024 -validity 365 -keystore server.keystore.jks -dname CN=server,ou=Users,dc=jboss,dc=org -keypass s