AS 7.1.0 Beta1 - Security Enabled By Default

Starting from the 7.1.0.Beta1 release we now have security enabled by default on the AS 7.1 distribution, the objective that we have been trying to achieve is to deliver an application server distribution where the management interfaces are secured by default to prevent unauthorized remote access whilst still allowing access for local users for an easier out of the box experience.

The Default Realm

The distribution exposes two management interfaces by default, one for HTTP access and one for Native access - both of these are secured using the same realm called 'ManagementRealm'.

The management realm is backed by a properties file used to store the users, the properties file is called 'mgmt-users.properties' and is stored in the configuration folder, depending on the mode you are running this will be one of the following: -

• {jboss.home}/standalone/configuration/mgmt-users.properties
• {jboss.home}/domain/configuration/mgmt-users.properties

The mgmt-users.properties file is monitored for updates at runtime so additions and removals from this file will be detected.

For authentication at the transport level we make use of Digest authentication, for this reason in the properties file instead of holding a plain text password we hold a hex encoded hash that consists of the username, the name of the realm, and the password. 

Despite hashed the contents of the file should still be considered sensitive and should be protected, the advantage of the hash is that it does make the contents specific to the realm in use and not applicable to different realms.

The users defined in this realm are used for the authentication of remote clients, for the definition of remote clients all HTTP access is considered remote so to make use of the admin console a user will need to be defined - tools such as the CLI will be able to make use of a local mechanism described below.

Adding New Users

To add new users to the properties file we now provide a utility to handle this, the utility can be triggered by running the add-user.sh or add-user.bat scripts in the bin folder of the AS 7.1 installation, this will trigger the following wizard: -

This utility requires three pieces of information for the new user: -

• Realm - this is the name of the realm used to secure the management interfaces, by default it is 'ManagementRealm' so you can just press enter, if you change the realm as described below this is where you need to enter your new realm name.
• Username - the username needs to be alpha numeric.
• Password - At the moment the main restriction on this field is that is can not be the same as the username.

As you can see from the output this will automatically update both of the properties files in the installation.

As a convenience the add-user.sh and add-user.bat scripts can take the username, password and realm in as command line parameters and the tool will then update the files non-interactively - however this is not recommended on shared systems as anyone inspecting running processes could see the plain text passwords.

If you are going to use this convenience approach the command syntax is: -

./add-user.sh username password

or

./add-user.sh username password realm

Generating the Hash

If you already have a database of users with their plain text passwords stored then you may like to generate the properties files youself - to generate the hashes you can make use of a utility class that we use ourselves.

The class is called 'org.jboss.sasl.util.UsernamePasswordHashUtil' and is within the 'org.jboss.sasl:jboss-sasl' maven artefact or the org/jboss/sasl module included with the AS distribution.

Using the above class the hex encoded hash can be generated as: -

String hash = new UsernamePasswordHashUtil().generateHashedHexURP(userName, realm, password);

This hash can then be appended to the properties file in the format username=hash

The reason an instance of UsernamePasswordHashUtil is used is because a MessageDigest is cached and can be used for subsequent generate requests.

Local Clients

After protecting the server from remote unauthorized access the next issue is providing the local user running the server access using tools such as the CLI, the Maven plug-in, JBoss Tools etc... without forcing the use of a username and password in this scenario.  For this case the user running the server would already have access to the configuration and could add their own user or disable the security checks so mandating that they enter a username and password is just complicating the local users experience.

For this scenario we have added a new SASL mechanism that is used internally by our client APIs, when this mechanism is selected the following sequence is followed to authenticate the user: -

1. Client sends message to server saying "I want to use the JBoss Local User SASL mechanism"
2. Server generates one time token, writes it to a unique file and sends message to client with full path of the file.
3. Client reads the token from the file and sends it to the server.
4. Server verifies token received and deletes the file.

This token is generated within the AS installation folder so for this mechanism to pass the client has demonstrated to the server that is both on the same host and that it has access to AS installation.

When deciding to implement this mechanism we did consider if we should just allow unauthenticated access to all local users, however on a multi-user system this could mean other users not intended to access the AS management would have access - with this mechanism in place those other users would not by default have access to the generated tokens.

Enhancing Security

As described above the contents of the property files make use of a hex encoded hash of the username, realm and password - to further enhance security it is recommended that you also change the name of the default realm to something else.

Note: As the hash is realm specific this change will need to be made BEFORE you add any users, changing the realm name will invalidate the contents of the property files.

To change the name of the realm edit either the standalone.xml or host.xml (as applicable) and change the following attributes: -

Where the actual is realm is defined the name will need to be changed.

<security-realm name="ManagementRealm">

Each of the management interfaces will need to be updated to reference the new realm name.

<native-interface security-realm="ManagementRealm">
<http-interface security-realm="ManagementRealm">

When using the command line ad-user.sh or add-user.bat scripts you will now need to enter the name of the new realm in response to the first question.