This documentation is for WSO2 Business Process Server 3.5.0. View documentation for the latest release.

Skip to end of metadata
Go to start of metadata

WSO2 Carbon is shipped with a Secure Vault implementation which is a modified version of synapse Secure Vault. This guide describes how to secure the plain text password in carbon configuration files.

Secret Manager

The Secret Manager initializes the Secret Repository and the keystores. It uses Secret Repository to keep the secret values (encrypted values). These secrets can be accessed through aliases. The keystore is required to create the decryption crypto, which can be used to resolve encrypted secrets values. The keystore and Secret Repository are configurable through the '' file found in the <PRODUCT_HOME>/repository/conf/security folder.

Secret Repository

This is used to store the secret values. Currently, there is only one Secret Repository implemented within Secure Vault: FileBaseSecretRepository. It uses, which can be found in the <PRODUCT_HOME>/repository/conf/security folder. It stores aliases vs. their actual secrets in encrypted format (encrypted via a key in keystore). Any secret repositories can be written by implementing the SecretRepository and SecretRepositoryProvider classes.

Secret Callback

This provides the actual password for a given alias. There is a SecretManagerSecretCallbackHandler, which is combined with Secret Manager to resolve the secret. Any callback can be written by implementing the SecretCallbackHandler class.

Secret Resolver

Any configuration builder that uses secret information within its own configuration file needs to initialize the Secret Resolver when building its own configuration. The Secret Resolver keeps a list of secured elements that need to be defined in the configuration file with secret aliases. Secret Resolver initializes the Secret Callback handler class, which is defined in the configuration file.

Use Secure Vault with default configuration

In default configuration,

  1. A file-base Secret Repository is used. The file can be found in the <PRODUCT_HOME>/repository/conf/security folder.
  2. Carbon Server's primary keystore is used for encrypting and decrypting passwords, which can be found in the <PRODUCT_HOME>/repository/resources/security folder.
  3. DefaultSecretCallbackHandler (org.wso2.carbon.securevault.DefaultSecretCallbackHandler) is used as the password resolver for the keystore and the private key passwords of the Carbon server's primary Keystore.
  4. SecretManagerSecretCallbackHandler (org.wso2.securevault.secret.handler.SecretManagerSecretCallbackHandler) is used as the password resolver for all the secret values that are defined in the Carbon configuration files.

The Secure Vault configuration is made easier by the command-line tool called Ciphertool.

Cipher Tool

By default, the CipherTool can be used for creating encrypted values for given plaint text. There are two options for Secure Vault configuration as follows:

- Dconfigure (sh -Dconfigure)
  1. This option allows the user to secure plain text passwords in carbon configuration files.
  2. Read alias values and their corresponding plain text passwords from the file. Note that the CipherTool identifies plain text defined within square brackets as the plain text passwords. If a password is not specified in the file for a corresponding alias, the user needs to provide it through the command-line.
  3. Check whether the alias is a known password alias in Carbon configurations. If the tool modifies the configuration element and file, then replace the configuration element with the alias name. Define a Secret Callback in the configuration file and add proper name spaces for defining the Secure Vault.
  4. Encrypt the plain text value using the primary keystore of the carbon server (Details of the primary keytore is taken from the carbon.xml file, which can be found in the <PRODUCT_HOME>/repository/conf folder.)
  5. Replace plain text values in the file with the encrypted passwords.
  6. Add the default configuration to file
-Dchange (sh -Dchange)
  1. This option allows the user to change a secured password.

The default Secret CallbackHandler

This Secret Callback handler is used to resolve the keystore and private key passwords of the Carbon server's primary keystore. As these passwords are needed to initialize the Secret Manager decrypted the encrypted values in the Secret Repository, they act as the root passwords for the Secure Vault. Therefore, DefaultSecretCallbackHandler provides two options for reading this password when starting the carbon sever.

Enter password in command-line

If option 2 is not configured, when the Carbon server is starting, it will prompt to enter the private key and keystore passwords. The admin starting the server must provide the private key and keystore passwords using the command-line. (Passwords are hidden from terminal and logs files.) By default, the password provider assumes that both private key and keystore passwords are the same. If not, the following system properties must be passed when the server is starting up.

export JAVA_OPTS=-Dkey.password=true (in UNIX)

This option is valid only when the Carbon server is started using sh When the server is started as a daemon, this option cannot be used.

Store the password in a temporary text file

When Carbon Server is starting, it first checks for the text file called "password-tmp" in <PRODUCT_HOME> and reads the private key and keystore password. The text file is deleted automatically after it is read. The admin who starts the Carbon Server must create a text file called "password-tmp" in <PRODUCT_HOME> and enter the keyStore password in the first line of the file. Steps are as follows:

  1. Shut down the server if it is already started.
  2. Create a text file named "password-tmp" in <PRODUCT_HOME>.
  3. Enter your primary keystore password in the first line of the text file and save.
  4. Start the Carbon Server using command, daemon. sh -start.
  5. By default, the password provider assumes that both private key and keystore passwords are the same. If not, the private key password must be entered in the second line of the file.

    Note that if you name the password file "password-persist" instead of "password-tmp", the file will not be deleted after the server starts. Therefore, it will not be required to provide the password when the server is started again. However, note that this method is not recommended in production environments.

    At every restart, the Admin has to create a text file.

Use Secure Vault with your own configurations

You can use your own configurations by changing the following according to your choice.

  • Secret Repository.
  • Secret Callback Handler.
  • Using a keystore other than the primary keystore of the carbon server.

Let's see how we can write a new Secret Callback Handler class to secure the user management and registry database connection password. In this sample, you do not need to configure a Secret Repository or keyStore ( as you are not going to store the secret or encrypted values.

Write a Secret Callback class. You need to implement the SecretCallbackHandler interface or extend the AbstractSecretCallbackHandler abstract class. For example,

We can set multiple password-based as follows,

Create a JAR or an OSGI bundle. Copy the JAR file to the <PRODUCT_HOME>/repository/component/lib/ directory or the OSGI bundle to the <PRODUCT_HOME>/repository/component/dropins/ directory. Configure the master-datasources.xml file with an alias name and your Secret Callback handler class name. For example,

Restart the server.

Secrets and alias list in Carbon configurations

Following are the alias names and secrets of carbon configuration files which are supported by Secure Vault.

  • No labels