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.
- - 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.
