One of the main problems we come across when configuring WSO2 is the privileged information we add to the configuration files themselves, such as a user that we want no one to know about, or a password that is intended for only one person to have access to. Also, when setting up a service, we define information that we do not want to be discoverable. So, which solutions does WSO2 provide?
What is Secure Vault?
WSO2’s Secure Vault is a tool that allows us:
- to encrypt values in the configuration files.
- to create aliases with encrypted values which replace unencrypted values in the configuration files, such as database or admin user passwords.
This WSO2 tool is created to give an extra layer of protection for certain credentials that we don’t want whoever has access to the configuration files to be able to discover.
Secure Vault can be used for different parameters, such as user data, passwords, database connections, or any other desired security setting.
Thus, it is an essential tool for the security of a company’s data.
Secure Vault Components
Cipher Tool
Secure Vault is made up of different elements, most of them being configuration files. The most important one is, without any doubt, the Cipher Tool.
The Cipher Tool is a script that changes depending on the operating system in which it is executed. We can find the ciphertool.sh for Linux, or the ciphertool.bat for Windows. This script uses a keystore (KeyStore), wso2carbon.jks. With this keystore, the tool will encrypt the defined values, and we will be able to use it through aliases.
The rest of the elements that form SECURE VAULT are:
Secret Repository
This is used to store secret, encrypted values. These values are shown by default before the Cipher Tool is activated, but they become encrypted after activation. The configuration file where these values are stored is “cipher-text.properties”, located in “${carbon.home}/conf/security/”. In this file, we will define some aliases and their respective passwords, as shown in the following image.
Here, we can see how some aliases (blue letters) and some values in brackets are defined. These values become encrypted after activating the Cipher Tool.
Besides this configuration file, we are provided with another configuration file “cipher-tool.properties”, located in “${carbon.home}/conf/security”. This configuration file is where we define the aforementioned aliases, and through xpath we will define the path containing that password or value to later be encrypted.
Secret Manager
This specifies the configuration of the Cipher Tool to encrypt the values that we have defined in the Secret Repository. Such settings include the file type, the path where that file is located, the password, its alias, the keystore (KeyStore), etc. In other words, it contains all the information that the Cipher Tool has used to encrypt the values. This file is “secret-conf.properties” which can be found in “${carbon.home}/conf/security”. This file exists by default, but all of its lines are included. It is when we start the Cipher Tool that this file becomes important, since certain settings are defined.
Secret CallBack
This provides us with the real password for a given alias. There is a SecretManagerSecretCallbackHandler, which teams up with Secret Manager to solve the secret. Any callback can be written by implementing the SecretCallbackHandler key.
–This article may be of your interest-
Secret Resolver
Any configuration creator using secret information within their own configuration file must launch the Secret Resolver when setting up their own configuration. Secret Resolver keeps a list of secure items that must be defined in the configuration file with secret aliases. Secret Resolver launches the Secret Callback controller class, which is defined in the configuration file.
If you want to know how Chakray can help you with Secure Vault and its components, then contact us!
