Cheat sheet: Wildfly Application Server

Abstract

This article contains information about the Wildfly Java Application Server in a compact format.

Enable SSL/HTTPS communication

Precondition

Provided: A PKCS12 Truststore file named truststore.pkcs12 with a domain certificate (you actually can use JKS as well) within the {$WILDFLY}/standalone/configuration directory.

Procedure

Using Wildfly 18 (and before) you can and should use the jboss-cli tool to configure the application server. You should actually avoid to manipulate the standalone*.xml or domain*.xml (for domain mode) file directly for a running instance, due to file corruption issues that might occur.

#cd {$WILDFLY_BASE}/bin
#./jboss-cli.sh (Use the .bat for Windows)

Connect jboss-cli to the local Wildfly instance:

[disconnected /] connect

Check the associated realm for the https-listener (here default “ApplicationRealm”):

[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)

{
"outcome" => "success",
"result" => "ApplicationRealm"
}

Configure the elytron security subsystem via a batch process:

[standalone@localhost:9990 /] batch
[standalone@localhost:9990 / #] /subsystem=elytron/key-store=demoKeyStore:add(path=truststore.pkcs12,relative-to=jboss.server.config.dir, credential-reference={clear-text=<Truststore Password>},type=PKCS12)
[standalone@localhost:9990 / #] /subsystem=elytron/key-manager=demoKeyManager:add(key-store=demoKeyStore,credential-reference={clear-text=<KeyManager Password>})
[standalone@localhost:9990 / #] /subsystem=elytron/server-ssl-context=demoSSLContext:add(key-manager=demoKeyManager,protocols=["TLSv1.2"])
[standalone@localhost:9990 / #] /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
[standalone@localhost:9990 / #] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=demoSSLContext)

Run the batch:

[standalone@localhost:9990 / #] run-batch

Reload the configuration:

[standalone@localhost:9990 /] reload

Servercluster: Using a Load Balancer and Working Nodes

Wildfly (since 10) comes with a preconfigured load-balancer profile, that we can actually use to distribute requests in a round-robin mechanism towards the working nodes. Wildfly’s load balancing subsystem is based on the mod_cluster load balancing system and uses its own distributed session manager component on top. This will make sure that the session state isn’t lost during delegation.

Load balancer

For standalone instances you can use the standalone-load-balancer.xml profile that is located under $WILDFLY/standalone/configuration.

Example usage for a private network:

./$WILDFLY/bin/standalone.sh -b $HOST_IP -bprivate $HOST_IP -c standalone-load-balancer.xml

Worker nodes

The worker nodes must run using the HA (or Full HA ) profile. I recommend the Full HA profile. The propagation takes place using UDP multicast, so actually no setup is required. The auto-discovery functionality will only work if load balancer node and worker nodes are in the same sub-net, otherwise you have to configure their network-addresses manually.

Example usage for a private network (for each node):

./$WILDFLY/bin/standalone.sh -c standalone-full-ha.xml -b $HOST_IP -bprivate $HOST_IP

Example configuration for worker nodes if UDP discovery doesn’t work:

export LOAD_BALANCER_IP=xxx.xxx.xxx.xxx

$WILDFLY/bin/jboss-cli.sh <<EOT
embed-server -c=standalone-full-ha.xml
/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=advertise,value=false)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=proxy1:add(host=$LOAD_BALANCER_IP,port=8090)
/subsystem=modcluster/mod-cluster-config=configuration:list-add(name=proxies,value=proxy1)
EOT

./$WILDFLY/bin/standalone.sh -c standalone-full-ha.xml -b $HOST_IP -bprivate $HOST_IP

Distributable WebApp

Your WebApp should be marked as being distributable. You only have to put a simple line in the web.xml to make sure that the Wildfly instances are aware of its intention:

<distributable />

That’s it. Then you have to deploy the WebApp to the elected master node of the cluster using the management console.

Appendix: Fundamentals

SSL/HTTPS Communication in Wildfly

SSL (Secure Sockets Layer)/HTTPS (HTTP Secure) is critical for securing communication between clients and servers, ensuring that data transmitted is encrypted and protected from interception. When implementing SSL/HTTPS in Wildfly, understanding the following aspects is crucial:

• PKCS12 and JKS: These are types of keystores. PKCS12 is a standardized format for storing cryptographic keys and certificates, while JKS (Java KeyStore) is Java’s proprietary keystore format. Wildfly’s support for both formats provides flexibility in choosing the appropriate keystore type based on security policies or compatibility requirements.
• Elytron Security Subsystem: Introduced in recent Wildfly versions, the Elytron subsystem provides a unified security framework that simplifies application security, including SSL/HTTPS configuration. It replaces the older security subsystems (PicketBox and JAAS) and offers enhanced capabilities for securing applications.
• TLSv1.2: This is the version of the TLS (Transport Layer Security) protocol used in the configuration example. TLSv1.2 introduces several cryptographic improvements over its predecessors, making it a secure choice for encrypting web traffic. Developers should be aware of the protocol version to ensure compatibility and security compliance.

Server Cluster Configuration

Server clustering in Wildfly enhances application scalability and availability. The configuration involves setting up a load balancer and multiple worker nodes:

• mod_cluster: This is a sophisticated load balancing solution that provides several advantages over traditional HTTP-based load balancing. mod_cluster offers dynamic configuration of HTTPD-based load balancers, intelligent load balancing based on server load, and fine-grained application lifecycle control.
• UDP Multicast: This technology enables the automatic discovery of cluster members without manual configuration. It’s crucial for environments where automatic discovery is feasible and desired. However, in cloud environments or specific network configurations, UDP multicast may not work, necessitating manual configuration.
• HA and Full HA Profiles: These profiles determine the clustering capabilities of Wildfly instances. The HA (High Availability) profile enables clustering features, while the Full HA profile includes all HA features plus additional ones, such as remote EJB invocation and distributed messaging.

Making WebApps Distributable

Marking a web application as distributable is essential for clustering. This setting instructs the application server to share session data among cluster nodes, ensuring session continuity even if requests are routed to different nodes. Developers should understand session replication mechanisms and potential impacts on performance and application design.

Advanced Considerations

• SSL/TLS Performance: Enabling SSL/TLS can impact server performance due to the additional computational overhead of encrypting and decrypting data. Developers should consider performance tuning options, such as offloading SSL processing to dedicated hardware or optimizing server configurations.
• Security Best Practices: Beyond enabling SSL/HTTPS, securing a Wildfly server involves a comprehensive approach, including securing management interfaces, applying the principle of least privilege, and keeping the server and applications up to date with security patches.
• Cluster Health Monitoring: Properly monitoring a Wildfly cluster’s health is critical for ensuring its reliability and performance. Tools like RHQ, JBoss Operations Network, or custom JMX monitoring scripts can help in monitoring cluster health and performance metrics.

Conclusion

In conclusion, configuring SSL/HTTPS communication and setting up a server cluster in Wildfly involves understanding a range of technologies and best practices. By diving deeper into the principles behind these configurations, developers can ensure their Wildfly servers are secure, scalable, and performant, ready to support enterprise Java applications in any environment.