WildFly Administration Remote Access

Refactor Java code safely — and automatically — with OpenRewrite.

Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.

Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.

Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.

Distributed systems often come with complex challenges such as service-to-service communication, state management, asynchronous messaging, security, and more.

Dapr (Distributed Application Runtime) provides a set of APIs and building blocks to address these challenges, abstracting away infrastructure so we can focus on business logic.

In this tutorial, we'll focus on Dapr's pub/sub API for message brokering. Using its Spring Boot integration, we'll simplify the creation of a loosely coupled, portable, and easily testable pub/sub messaging system:

>> Flexible Pub/Sub Messaging With Spring Boot and Dapr

1. Introduction

WildFly provides different approaches for server administration. The most familiar approach is to use its web interface, but we can use the CLI or XML scripts.

In this tutorial, we’ll focus on accessing the administration web interface.

We’ll assume that readers already understand the standard WildFly Setup process.

2. Remote Access

The web interface or console is a GWT application that uses WildFly’s HTTP management API to configure either a standalone or a domain-managed server. This API serves two different contexts:

Web interface: http://<host>:9990/console
Management operations: http://<host>:9990/management

By default, the web console is only accessible from localhost. That is to say, our configuration files contain only local interfaces to interact with a web console.

In WildFly jargon, an interface consists of a network interface with selection criteria. In most cases, a selection criterion is the bound IP address to the interface. The local interface is declared as follow :

<interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
</interface>
<!--127.0.0.1 is the localhost IP address. -->

As a result, this management local is attached to socket listener management-http receiving connections for web console from port 9000:

<socket-binding-group name="standard-sockets" default-interface="public" 
  port-offset="${jboss.socket.binding.port-offset:0}">
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="management-http" interface="management" 
      port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="management" 
      port="${jboss.management.https.port:9993}"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <outbound-socket-binding name="mail-smtp">
       <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

To allow access from a remote machine, we first need to create the remote management interface in the appropriate configuration file. If we’re configuring a standalone server, we’ll change standalone/configuration/standalone.xml, and for domain-managed, we’ll change domain/configuration/host.xml:

<interface name="remoteManagement">
    <inet-address value="${jboss.bind.address.management:REMOTE_HOST_IP}"/> 
</interface> 
<!--REMOTE_HOST_IP is the remote host IP address. (e.g 192.168.1.2) -->

We must also modify the socket binding of management-http to delete the previous local interface and add the new one:

<socket-binding-group name="standard-sockets" default-interface="public" 
  port-offset="${jboss.socket.binding.port-offset:0}">
    <!-- same as before -->
    <socket-binding name="management-http" interface="remoteManagement" 
      port="${jboss.management.http.port:9990}"/>
    <socket-binding name="management-https" interface="remoteManagement" 
      port="${jboss.management.https.port:9993}"/>
    <!-- same as before -->
</socket-binding-group>

In the above configuration, we bind the new remoteManagement interface to our HTTP (9990) and HTTPS (9993) ports. It’ll allow the remote host IP to connect to the web interface through HTTP/HTTPS ports.

3. Authentication

WildFly secures all remote connections by default. The default security mechanism is a username/password via HTTP digest authentication.

But, if we attempt to connect to the admin console before we’ve added a user to the server, we won’t be prompted with login popup.

To create users, then, WildFly provides an interactive add-user.sh (add-user.bat on Windows platforms) script with several steps:

Type of user: Either management or application user
Realm: The realm name used in the configuration, which is ManagementRealm by default
Username: The new user’s username
Password: The new user’s password
Slave domain controller: A flag indicating whether the user will control slave domains processes in a distributed-domains architecture; it defaults to No

It’s also possible to add users in a non-interactive way by making use of the same script and specifying the input as parameters:

$ ./add-user.sh -u 'adminuser1' -p 'password1!'

adds a management user “adminuser1“ with the password “password1!” to the default realm.

4. Conclusion

In this short tutorial, we explored how to setup WildFly to allow remote access to the management web console of the server. Furthermore, we also saw how we can create users using WildFly’s provided scripts.