Mule Credentials Vault

Imagine a situation in which a developer is tasked with designing a Mule application for the Human Resources department which must access a secure database of private employee information. An HR employee – an authorized end user of the Mule application – submits a request for information, say, an employee’s base salary, and the Mule application must access a secure database to retrieve the information. One cannot access this HR database without valid login credentials, so the developer must design the Mule application to access the database, yet keep the database login credentials secret.

First, the developer designs the application to process HR end user requests, which includes a call to the secure database. He then creates a Mule Credentials Vault to store the database login credentials, or properties. In the context of Anypoint Enterprise Security, the properties file which stores encrypted properties is the Credentials Vault. When he adds data to the properties file, Mule gives him the option to encrypt the data. He chooses an encryption algorithm (of the 19 available), then enters an encryption key. That encryption key is the only way to decrypt the properties in the properties file. In other words, the encryption key is the only thing that unlocks the Credentials Vault.

Next, the creates a global Secure Property Placeholder element which locates the Credentials Vault (i.e. properties file), then retrieves encrypted properties. However, the Secure Property Placeholder can only access the Credentials Vault (i.e. decrypt the data) if it has the key.

Now he has data in a vault and a mechanism to request the data, but where is the key to unlock the vault (i.e. decrypt the data)? And how does the developer ensure that the key is not accessible by everyone with access to the application? If he were to simply hardcode the key into the configuration of the global Secure Property Placeholder, any colleague with access to the application could simply read the key and unlock the vault. The developer, therefore, configures the Secure Property Placeholder to use the key that Mule collects from the user at runtime (see code below). In this context, the key to decrypt the properties becomes a runtime password.

At runtime (i.e. when you run the Mule application on premises or in the cloud), Mule demands that the user (for example, an Operations Administrator) enter a key, which Mule stores in-memory. Recall that the key that Mule demands at runtime is the same key the developer used to encrypt the properties in the Credentials Vault; the developer in this scenario had to have manually given the key to the person who is responsible for running the application, such as an Ops Admin. Whenever a Secure Property Placeholder within the Mule application must unlock the Credentials Vault to retrieve HR database login credentials, it uses the key the Ops Admin entered at runtime. Conveniently, Mule remembers the key for the duration of the Ops Admin’s session so as to avoid demanding a key each time a Mule decrypts a property in the vault. However, when the Ops Admin ends the Mule session (i.e. terminates the application), Mule discards the key.

To configure Mule to demand that the user enter a key at runtime, the developer includes the following in the system properties (the mule-app.properties file in the src>main>app folder):

When it needs the key to decrypt the contents of the properties file, the secure properties placeholder asks Mule’s system properties file, which uses the in-memory key as entered by the Ops Admin.

In Mule, you can set up several variations of of the Placeholder-Vault-Key relationship.

To use the Mule Credentials Vault, you must perform three tasks:

The following sections describe how to complete these three tasks.

A company has built a Mule application which connects to the Salesforce API. The application stores Salesforce login credentials for all its users. Developers who work on the application must be able to test Salesforce connection functionality, but must not be able to access the users’ Salesforce account information. Therefore, the application has two properties files, one for the production environment of the application, and one that the developers can use to test functionality.

The test.prod.properties file stores encrypted contents in the Mule Credentials Vault; the test.dev.properties file stores unencrypted information inside properties file. At runtime, Mule behavior differs according to environment.

Because the developers do not have the prod.key value (i.e. the runtime password, which is also the key to access the Credentials Vault), they cannot access the secure Salesforce login credentials in the test.prod.properties file. The only one who knows the prod.key is the Operations Team Lead who deploys the application into production.

When the Ops Team Lead starts Mule, Mule demands that he enter the` prod.key` for the Credentials Vault (see command below). Mule accepts the prod.key as valid for the duration of the Ops Team Lead’s Mule session. When he quits the application, Mule forgets the prod.key.