API ACCESS CONTROL
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
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.