Security

It is critical to ensure that the valuable information that a business stores and makes available through software applications and web services is secure, protected from unauthorized users and malicious attackers. But it is also critical that these protected resources, such as credit card information or Social Security numbers, be immediately accessible to authorized, legitimate users and systems to conduct business transactions.

To provide secure access to information, applications and services can apply a variety of security measures. Mule runtime engine (Mule) provides several tools and methods that enables you to protect applications:

Securing application configuration properties
Using the Cryptography module
Configuring a FIPS 140-2 certified environment
Securing flows with Spring security
Configuring TLS cryptographic protocol
Obtaining access to protected resource using Oath Authorization Grant Types
Configuring the Mule Secure Token Service

Configure Properties- Best Practices

Properties files are a means of abstracting configuration settings away from the running MuleSoft flow. Properties files can live inside MuleSoft package, inside the classpath defined by package and runtime and/or properties tab of the Mule applications in CloudHub. Using properties files is the best approach as it allows Operational staff to modify configuration parameters and can also support encrypting values.

Passwords / URLs / Usernames / Database Names / connection strings / SalesForce Tokens/JMS/ MQ queues and topics names should never be hardcoded.
To avoid hardcoding – use Configuration Properties in Anypoint Studio

Example:

Store properties files in

src/main/resources/configure>/.yaml

Make sure to use .yaml file for configuration as shown above.
When naming properties inside a configuration files make use of Dot-notation where necessary to ensure properties are classified in a logical pattern. These become more clear to the reader and easier to update / search for.

Example:

Salesforce:
username: “<>”
password: “<>”
keystore:
key.password: “<>”

In addition to naming – keep the configurations in logical groups in the file
Be careful of special characters and where the values may be used. Some connectors may not like @ symbol or other symbols and need to be escaped

Encrypt/Decrypt Properties –

Using the Secure Properties Tool

Use the Secure Properties Tool to encrypt or decrypt text strings, values inside a properties file, or all the contents of a properties file.

Ensure that you have the latest available version of this tool to use all the functions detailed in this article.
Download link: Secure Properties Tool Jar file.

Encrypt Text Strings

Use the following syntax to encrypt or decrypt a text string provided as a parameter:

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \
<method> \
<operation> \
<algorithm> \
<mode> \
<key> \
<value> \
--use-random-iv [optional]

Set <method> to string to configure the tool to process a text string.
Specify the other parameters to perform your desired operation.

For example, if you run:

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \
string \
encrypt \
Blowfish \
CBC \
mulesoft \
"some value to encrypt"

The tool returns:

8q5e1+jy0cND2iV2WPThahmz6XsDwB6Z

Encrypt Files

In addition to processing strings, the encryption tool processes .yaml or .properties files. You can encrypt or decrypt the values inside a properties file, or all the file’s content.

Encrypt Properties Inside a File

Use the following syntax to encrypt or decrypt all values inside a properties file:

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \
<method> \
<operation> \
<algorithm> \
<mode> \
<key> \
<input file> \
<output file> \
--use-random-iv [optional]

Set <method> to file.
Set <input file> to the properties file to process.
Set <output file> to the file that is generated after the process.
Specify the other parameters to perform your desired operation.

For example, consider the file example_in.yaml with the following content:

properties:
  example1:
    value: "Muleman is here"
  example2: "Max the mule"

If you run:

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool \
file \
encrypt \
Blowfish \
CBC \
mulesoft \
example_in.yaml \
example_out.yaml

The tool generates the file example_out.yaml with the following content:

properties:
  example1:
    value: "![qCReIPK3jcqD7WR84ISSIQ==]"
  example2: "![En8lII21ZHrdIaINw0+mSA==]"

Configure the File with the Extension Module in XML

In your XML flow, use the module <secure-properties:config> to configure the file. Review the following example:

Secure Configuration Properties with Default Values

<secure-properties:config key="${runtime.property}"
  file="file1.yaml" name="test">
    <secure-properties:encrypt/>
</secure-properties:config>

<global-property name="prop" value="my-${secure::property.key1}"/>

The <secure-properties:encrypt> tag is required even when using the default values.

The prefix secure:: is required for loading the key.

You have to use the secure:: prefix to access all values inside a secure properties file, even if the values are not encrypted. Doing this enables you to switch between files (or environments) without changing the entire configuration.

At deployment time, a decryption key is passed into the Mule runtime engine as a system environment variable runtime.property. This property must be the exact key used to encrypt the values stored in the file1.yaml file.
The default encryption algorithm and mode is used.
If the actual (decrypted) value of the property property.key1 is, for example, "property", the value of the property prop is "my-property".

Supported Algorithms and Modes

Supported Algorithms

AES (default)
Blowfish
DES
DESede
RC2
RCA

The following algorithms can be used only if you configure a Java Cryptography Extension (JCE) Provider that adds support for them:

Camellia
CAST5
CAST6
Noekeon
Rijndael
SEED
Serpent
Skipjack
TEA
Twofish
XTEA
RC5
RC6

Supported Modes

CBC (default)
CFB
ECB
OFB

Conclusion

Environment specific property configuration file will store the properties required for the applications
To run the application on the developer machine use the local/dev properties
When deployed to on-premise shared environment, the environment specific properties will be overridden from external file location
Before committing the changes to code repository, consider using MuleSoft credential vault/secure configuration jar file to encrypt the passwords.
It happens, most of the times we need to store sensitive data like user ID, password and other credentials in a mule project. We can store the plain text credentials in the project code repository, but this would allow everybody with access to the repository to use these credentials.
The main focus of mule secure properties is to make sure that our sensitive data like User ID and Password is safe (encrypted/cypher-text) from any destructive forces.
Data is stored in the property file as key value pair. This property file can store information like User ID, Password and other sensitive data. After storing these data in the property file, we need encryption to restrict unauthorized access and to protect the data.