JBoss EAP simplifies a lot of server configuration by consolidating all subsystem configurations into a single XML file (standalone.xml or domain.xml). This, however, can expose sensitive information to any user that has access to the configuration files. For example, datasource credentials are by default stored in plain text in the XML file. In this blog I will show you how to protect your passwords!

What is the vault password?

The vault encrypts sensitive strings, stores them in an encrypted keystore, and decrypts them for applications and verification systems. To avoid leaving sensitive credentials readable in the standalone.xml or domain.xml files, you can store passwords or other attributes in the vault and then reference the vault from within the server configuration file.

Using a vault creates a level of abstraction and obfuscates data which could otherwise be read by anyone who has access to the configuration files. Please note that the access to the configuration files should be anyway restricted.

Create a Java Keystore to store sensitive strings

The vault utilizes a keystore by using the certificate stored in the keystore as an encryption key for the vault as a whole. To initialize the vault, users need to first create the JavaSE keystore. The following is the syntax used to create a private key, a certificate and to store them in a keystore:

keytool -genseckey -alias <alias> -keyalg <algorithm> -storetype <type> -keysize size -keystore <filepath>
  • alias: The alias is a unique identifier for the vault or other data stored in the keystore.
  • keyalg: The algorithm to use for encryption.
  • storetype: The keystore type. jceks is the recommended type.
  • keysize The size of the encryption key which determines the difficulty in brute forcing the
  • keystore: The file path and file name in which the keystore’s values are stored.

The below is an example:

[jboss@vmjboss jboss]# keytool -genseckey -alias vault -keyalg AES -storetype jceks -keysize 128 -keystore /app/jboss/vault.keystore
Enter keystore password:  
Re-enter new password: 
Enter key password for <vault>
	(RETURN if same as keystore password):  

The JCEKS keystore uses a proprietary format. It is recommended to migrate to PKCS12 which is an industry standard format using "keytool -importkeystore -srckeystore /app/jboss/vault.keystore -destkeystore /app/jboss/vault.keystore -deststoretype pkcs12".
[jboss@vmjboss jboss]# ls -rtl /app/jboss/
total 4
-rw-r--r-- 1 jboss jboss 500 Sep  4 10:56 vault.keystore

After running the command, you will be prompted for a keystore password and a keystore file will be created at /app/jboss/vault.keystore.

Using the vault

The vault can be initialized either interactively, by providing each parameter one at a time, or by providing all of the parameters initially.

The following is an example of the syntax used to initialize the vault:

vault.sh --keystore KEYSTORE_URL --keystore-password KEYSTORE_PASSWORD --alias KEYSTORE_ALIAS --vault-block VAULT_BLOCK --attribute ATTRIBUTE --sec-attr SEC-ATTR --enc-dir ENC_FILE_DIR --iteration ITERATION_COUNT --salt SALT

The following parameters are required to initialize the vault:

  • KEYSTORE_URL: The path to the previously created keystore file.
  • KEYSTORE_PASSWORD: The password to access the keystore that was used at the keystore’s
  • SALT: A random string of eight characters used to encrypt the attribute stored in the vault.
  • KEYSTORE_ALIAS: The alias that identifies the certificate stored in the keystore.
  • ITERATION_COUNT: The number of times encryption is run.
  • ENC_FILE_DIR: The path where the encrypted files are stored.
  • VAULT_BLOCK: The name to be given to the block in the vault.
  • ATTRIBUTE: The name of the attribute being stored. For example, “password” as an attribute
    name when storing a password value.
  • SEC-ATTR: The value being stored.

The following is an example with the parameters populated:

[jboss@vmjboss bin]# vault.sh --keystore /app/jboss/vault.keystore --keystore-password password --alias vault --vault-block blog --attribute password --sec-attr blogpass --enc-dir /app/jboss/ --iteration 50 --salt 12345678

After running the vault.sh command, an XML definition of the vault is displayed, which needs to be added to the server configuration files. The following is an example of the XML that needs to be added to either the standalone.xml or host.xml configuration file directly before the section:

<vault-option name="KEYSTORE_URL" value="/app/jboss/vault.keystore"/>
<vault-option name="KEYSTORE_PASSWORD" value="MASK-31x/z0Xn83H4JaL0h5eK/N"/>
<vault-option name="KEYSTORE_ALIAS" value="vault"/>
<vault-option name="SALT" value="12345678"/>
<vault-option name="ITERATION_COUNT" value="50"/>
<vault-option name="ENC_FILE_DIR" value="/app/jboss/"/>

The final step is to replace the sensitive data with a reference to the attribute in the vault. The vault.sh command provides the exact syntax necessary to reference the secured attribute after all of the parameters are provided. Using the previous example, the vault command generated the following:


In order to use this reference, use the following syntax within the server configuration:


The following can replace the previous password in the server configuration for the blog datasource password:


After replacing the password for the datasource, the server configuration for the datasource will look similar to the following:

<datasource jndi-name="java:jboss/datasources/blogope" ...>

In this blog we saw how to protect passwords or any sensitive data in configuration files. Don’t forget to restrict the access to your configuration files also!

Don’t hesitate to comment this blog, for any question or to share your experience with vault within JBoss EAP.

Some blogs around JBoss EAP: