Enforce strong Access Control on top of APIs and SaaS endpoints using Enzo's ACL mechanism, allowing your organization to define who can read, write, administer and monitor/integrate with those endpoints.

Organizations dealing with hosted platforms, such as SharePoint or SalesForce, or with public facing services such as Twitter or Twilio, need a consistent mechanism to provide proxy accounts with limited access rights so that only the necessary methods/operations are made available to the desired individuals/applications. No developer should ever need to know API keys and secrets or production passwords.

Access Control Lists

Enzo proxies access to sensitive systems, such as SharePoint and SalesForce, so that end users and applications never have the actual credentials of the source system. This in turn allows administrators to enforce granular ACLs mapped to the proxy accounts.

Example 1: Joe works in the development department, and Jane works in the Marketing department. Enzo can be configured so that Joe can only read using the company's twitter account, while Jane can read and post tweets.

Example 2: Regardless of Bob's actual access rights in SharePoint, Bob can read from SharePoint lists through Enzo, but cannot add/update list items programmatically using REST or SQL commands.

REST and SQL ACL

The same ACL works whether the caller uses a REST call or an SQL command. Enzo maps the credentials used by the caller to the user in Enzo, and assigns the proper ACL accordingly. In other words, the ACL is created once for a user, and is applied immediately for both REST and SQL calls.

Example: Joe was granted access to the Twitter API to search for recent tweets. Whether Joe uses a REST call, or an SQL command, the same restrictions will apply.

RELATED

Configuration Secrets Vault