Hide Passwords with Password Aliases in Payara Server

Introduction

When performing the configuration of the Payara Server for your application, you often need to supply a password. The password to connect to the database is a classic example, but there are many situations where you need to enter this kind of sensitive data.

With Payara Server, you have the option to hide this kind of sensitive data from the user, so that this information is much better secured.

Password Alias

As an example, here’s the procedure for hiding the actual password for a database connection. But the feature can be used in a much broader context. It is not limited to only the password field of the database connection where it is supported but it is part of the variable substitution feature of the Payara Platform.

But first, let us have a look at how you can create a password alias. There is an asadmin command to create such value. The command is as follows:

./asadmin create-password-alias dbpass
Enter the alias password> 
Enter the alias password again> 

You explicitly need to type the password in (and retype it) and you cannot specify it on the command line. This to prevent the password from being stored in your command line history.

You can list all the aliases that are known by the system with the following command:

 ./asadmin list-password-aliases

But you cannot list the actual value of the password.

The same functionality is also available within the Web Administration Console:

It lists all available Password Aliases in the domain, you can create and delete them and change the value of it. Make sure that the Secure Admin option is enabled by Payara Server so that the contents of the password Alias are sent encrypted (through SSL) to the server.

Once you have the Password Alias in place, you can use it to define the value for the password in the database connection field. With the field, you can place the following info:

${ALIAS=dbpass}

When the Payara Platform resolves the values, it looks up the Password Alias and decrypts the value. This value is only present in memory and never stored.

This way, you can define sensitive values but they never show up in the output of an asadmin command or on the Web Administration Console screens.

As already mentioned, the support is not limited to the password field but the Password Alias can be used at all locations where variable substitution is supported. This includes XML descriptor files, annotations, properties files, and more. For a comprehensive list, you can have a look at our documentation.

But the values can also be retrieved at runtime so that your code can also make use of the sensitive data. An example is the private key that is used to sign the JWT message that you send to a remote service. An example is the private key that is used to sign the JWT message that you send to a remote service.

The following code snippet injects the value into a property using the MicroProfile Config functionality:

 @Inject
 @ConfigProperty(name = "dbpass")
 private String password;

Our MicroProfile Config implementation includes a Config Source that looks up the key as Password Alias. If found, it decrypts it and returns the value.

Behind the Scenes

The encryption of the value makes use of the KeyStore functionality of the JVM itself. It uses the master password and a random value to generate a symmetric key (Password-Based Encryption). This key is used to encrypt the value of the Password Alias. The key used to encrypt the value itself is never stored in the configuration directory, only the random value, and the resulting encrypted value.

Based on the stored random value, the symmetric key can be reconstructed using the master password and the encrypted value can be decrypted to its original value.

It is safe to change the Master Password in the situation you have some Password Aliases stored. Actions are performed to make sure the value can still be used with the new master password.

Conclusion

Payara Platform’s Password Alias feature makes it easy to support sensitive values. Those sensitive values, such as passwords, are no longer used in commands and on the pages of the Web Administration Console. They are encrypted and stored in the domain configuration and only the values are referenced by a name. Those references do not expose the value and thus the sensitive data are stored safely.