A security realm comprises mechanisms for protecting resources in an application server. Each security realm consists of a set of configured security providers, users, groups, security roles, and security policies. A user must be defined in a security realm in order to access any resources belonging to that realm. When a user attempts to access a particular resource, the application server tries to authenticate and authorize the user by checking the security role assigned to the user in the relevant security realm and the security policy of the particular resource. In the standalone.xml file, we can see the default security realm configuration working with HTTPS:

<security-realm name="ApplicationRealm">
  <server-identities>
    <ssl>
      <keystore path="application.keystore" relative-to="jboss.server.config.dir" keystore-password="password" alias="server" key-password="password" generate-self-signed-certificate-host="localhost"/>
    </ssl>
  </server-identities>
  <authentication>
     <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
     <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
  </authentication>
  <authorization>
     <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
  </authorization>
 </security-realm>

The SSL connection is ensured by the default keystore, the application.keystore that manages the crypting keys used to encrypt the connection. In this example, the authentication is managed through keys inside the file application-users.properties. In this file, you can add a row containing user and password to authenticate in your web apps. Here is a sample:

admin=2a0923285184943425d1f53ddd58ec7a

The password is an Md5 encrypted string. It's a good practice use this system to preserve the passwords in the filesystem.

The authorization is done by the application-roles.properties file:

admin=PowerUser,BillingAdmin

In this case, the admin user will have the roles PowerUser and BillingAdmin. Those two files can be updated through the command-line script sited in the bin directory of WildFly add-user.sh. When you start this command, you must respond to the following questions:

bash-3.2$ ./add-user.sh
What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
(a): b
Enter the details of the new user to add.
Using realm 'ApplicationRealm' as discovered from the existing property files.
Username : my-user
Password recommendations are listed below. To modify these restrictions edit the add-user.properties configuration file.
 - The password should be different from the username
 - The password should not be one of the following restricted values {root, admin, administrator}
 - The password should contain at least 8 characters, 1 alphabetic character(s), 1 digit(s), 1 non-alphanumeric symbol(s)
Password : 
WFLYDM0101: Password should have at least 1 digit.
Are you sure you want to use the password entered yes/no? yes
Re-enter Password : 
What groups do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: admin
About to add user 'my-user' for realm 'ApplicationRealm'
Is this correct yes/no? yes
Added user 'my-user' to file '.../application-users.properties'
Added user 'my-user' with groups admin to file '.../application-roles.properties'
Is this new user going to be used for one AS process to connect to another AS process? 
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="bXktcGFzc3dvcmQ=" />

Reopening the application-user.properties file, we will find the new user:

my-user=5222410df4f506c6ab5637f07624364b

And application-roles.properties set to admin:

my-user=admin

As we can see in the aforementioned code list, we have two types of users--management users and application users. Management users work only in administrative applications as the web console or JMX systems, while application users work in developed custom applications as webapps or EJB applications.

The web server is configured here in the standalone.xml file:

<server name="default-server">
  <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
  <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
  <host name="default-host" alias="localhost">
     <location name="/" handler="welcome-content"/>
     <filter-ref name="server-header"/>
     <filter-ref name="x-powered-by-header"/>
  </host>
</server>

To the web server is associated a HTTPS listener that will be active for each HTTPS call by the browser or another web client. This listener is configured to use the application realm seen before.

Of course, the default certificate cannot be used in a real situation. An X.509 certificate must not be known by all, so it's always important set your own certificate. After that, it needs to be verified by an authority provider to acquire security. The most famous are VeriSign, GeoTrust and Comodo.