ProcessMaker I/O, a new product by ProcessMaker Inc., is the market leading Workflow-API-as-a-Microservice. ProcessMaker I/O is a solution built for ISVs and developers that want to extend their product offering with best in class workflow and connectivity features under a white label OEM model (API-as-a-Service). Target customers include CRM, ERP, iPaaS, BPM, MDM, Billing Systems, Forms products, Mobile platforms, and other enterprise ISVs.
Now, ProcessMaker I/O has released the first iteration of a new feature called Secure Vault. Secure Vault provides secure, centralized storage inside a ProcessMaker I/O Environment to store abstracted security credentials that will be used in connectors, workflows, actions, and processes in ProcessMaker I/O.
Use Secure Vault to store values that should be protected, such as passwords, access tokens, secure keys, and more. In fact, we even recommend that database connection hostnames and Slack channels be stored in your Secure Vault.
Reasons for Abstracting Security Credentials
There are two main reasons to abstract usage of your keys, tokens and identifiable service addresses like hostnames:
- Security – You should not hardcode these values into parts of your process that will need to be shared with multiple parties. Process snippets that contain keys and reference-able names tend to be copied and shared; this is a secure risk for your company. Even worse, some services and scripts require a root/admin permission for the implementation. Without a way to store protected values, this would be a problem because your developers would need full access to these root/admin combinations. This becomes a compliance issue from a security standpoint. A feature inside Secure Vault, called Secure Secrets, eliminates this problem by abstracting the protected value with a key that serves as a reference for the key-value pair.
- Maintenance – Do you really want to have to skim through connectors, triggers, and xml code to make changes to credentials from dozens of different SaaS providers you work with when/if those credentials change? The answer is “no” – this should be maintained in a single repository that can be updated by the person in charge of security for your system.
How it works
- Open Vault Work Area – Open the secure vault work area inside a workspace by clicking on the Secure Vault menu.
- Add Secure Secret Value – Click Add Secure Secret to add a new key that you want to store in your Secure Vault.
- Provide a name for your key – When you add a Secure Secret, provide the name you want to use as the “key.” Use this name to call your key when you want to use it in a process (this would be done in a connector inside a service task or inside a script task).
- Add the provider-issued value for the key – Lastly, add in the secure value:this is the value of the key that is provided to you by the provider that issued the key to you and this is what gets securely stored in the Secure Vault.
Using your Vaults via APIs
Like all other parts of ProcessMaker I/O, we have CRUD APIs so that you can utilize your secure vault directly from within your software (the ISV software).
- listSecrets – gets a list of all of the secrets that have been added to the secure vault storage area
- addSecret – adds a new secret to your vault
- findSecretById – find a secret by using its ID or Key
- updateSecret – updates an existing secret value. You cannot update the secret’s key, only the associated value.
- deleteSecret – deletes a secret by using the secret ID or Key.
How to work with Secure Vault
If you don’t have a ProcessMaker I/O Environment, do the following:
- Create a new account if you don’t already have one.
- Click the Tab Environments.
- Click Create Environment and follow the instructions provided.
If you already have a ProcessMaker I/O Environment, do the following:
- Run a ProcessMaker I/O Environment from the Environment tab.
- Click the Secure Vault tab.
- Click the “New Secret” button.
- Enter the Key, Value, Name and Description.
- Click the “Add ” button.
- Use the Secret key in the Process Scheme when you configure the Input parameters for the connector.
For example, the value of the parameters should be:
{pmio.vault.[SECRET_KEY]}
As example, for the input parameter of the Adobe Sign Connector it will be
{pmio.vault.adobe_sign_client_id}
or in the xml:
{pmio.vault.adobe_sign_client_id}
Next Phase
As you can imagine, for our Secure Vault Storage area to be truly secure, we need to encrypt it. We will add encryption in our next release. In the meantime, have a look at what we have created and give us your feedback!