Live API Security from Espresso Logic, Inc. on Vimeo.
Espresso Logic/Security enables you to control data access down to the row and column instance level. You configure Security using the Logic Console as shown here.
Espresso Logic provides:
This page describes several security concepts that you will need to understand to make effective use of the security services.
Dev vs. App Security
When you registered for Espresso, you received an email to access the Logic Designer. This is Dev Security. This is essentially authentication with "root privilege" to the system, providing not only database access, but the ability to alter logic, define security, and so forth.
The discussion below is a completely different topic. It pertains to User Security, namely, who can access the API (the data, such as by Live Browser), and what are they authorized to do. Such users are not provided access to the definitions of security, resources, logic, and so forth.
Security begins with Authentication, to determine whether a user is defined and has valid credentials. You can define Users using Espresso, or provide an Authentication Provider service that uses corporate information in LDAP, Active Directory etc.
In any case, the result is set of authorized Roles. You use the Logic Designer to define Role Permissions as a set of filters on designated tables. Authorization means these filters are automatically injected into all REST requests.
Each role defines Permissions for table access. As shown here, Permissions include both Predicates for row access, Columns, and Access Type to determine the operations allowed. A role is authorized to the union of its permissions, and an Api Key is authorized to the union of all is role-based permissions.
An Api Key typically represents an authorized user, and defines the set of Roles to which the user is authorized. There are usually far fewer roles than users, so Roles make administration much simpler than assigning authorization directly to Users.
A particularly important concept is the set of Globals. Defined for a role, these variables can be used in Predicates and Rules.
Security entails 2 key operations:
Espresso Logic provides options for https-based communications. Please contact us regarding this option.
Service connectivity is controlled by your Authentication Provider.
For further control, Espresso Logic provides options to deploy services within a Private Cloud. Please contact us regarding this option.
Cross Origin Resource Sharing (CORS)
is the mechanism to enforce this restriction.
Database Connection Security
Espresso Logic requires access to your database. Your information is protected by both encryption and salting, using industry standards.
There are two common database location scenarios:
- Cloud Database - it is becoming the common practice to deploy databases in the cloud, for automated maintenance and administration. To minimize latency, select an Espresso Logic Service on the same cloud provider and region as your database
- On-premise database - where services are required for a database already deployed behind your firewall, contact your network administrator to authorize access by the Espresso Logic. There are two basic approaches:
For On-premise databases, you will need the public cloud IP address of your Espresso Logic Virtual Machine, which is available through support or the online chat.
For advanced security, contact us to discuss providing Espresso Logic in your private cloud.
For organizations with rigid security requirements, contact us to discuss an On-premise Espresso Logic virtual machine. This will generally not include elastic support to dynamically add servers.
Security is very powerful, and also complicated. Here
are some examples to consider once you've reviewed the concepts.