Docs‎ > ‎Logic Designer‎ > ‎Security‎ > ‎

Authorization

Once an API call has been authenticated, the server determines what that call is authorized to do by looking at the roles assigned to the API key.  The sections below explain the basic facilities, which you can see in use in the Security Samples.

Role Default Access Levels

As shown below, you can specify a default read / write access for a role.  These apply in to all tables not specifically defined in the Role Permissions.



Role Permissions

As shown below, you can define one or more Permissions entries that specify:

Permission Properties

Each Role Permission has the properties described below.

Table

the Table the permission applies to.  You can have multiple permissions entries for a given table as shown below for Products

Permissions Name

Enables you to identify the entry within the list

Access Type

For rows that meet the Predicate, this indicates whether the row can be read or written.  You could, for example, enable rows to be inserted, but not read back

Columns

Which columns are allowed for the enabled Access

Predicate

A selection filter appended to all Requests against this table.   To illustrate Predicates, we might have a Security attribute (high, low) for a table, so that only Admin roles can read high security rows.

Multiple Permissions for a table

Importantly, you can define multiple Permissions for a given table.  These are added together over all of the roles for the current Api Key. 


Globals

Predicates become particularly powerful when they represent not only constant expressions, but expressions that refer to Globals.  There are two kinds of Globals:
  • Global Values: a named value, such as Clearance whose value may be Low, Medium or High
  • Globals Objects: a named map of keyword/value pairs.   In particular, the Global Value name/value pairs can be a database row.
The following subsections describe how you can refer to and create Globals.

Global References

Globals can be referenced as follows:

@{<globalName>}                                          // reference a Global Value
@{<globalName>.<globalAttribute>}  // reference attribute of Global Object

Globals are not restricted to Security Predicates.  You can make global references in any of the contexts listed below:

 Global Reference      Notes
 Security Predicate  
 Resource Filter  eg, screenName = '@{_apikey.user_identifier}'
   salesrep_id = @{current_employee_row.employee_id}
 Resource SqlFrom  
 Rule Expressions  You can reference globals in expressions for formulas and validations
 Typical examples might include user id/name update and insert stamping
 JavaScript  LogicContext provides access to globals


Global Definition Sources

Globals can be defined in a number of ways as described in the following sub-sections.   Global References described above are independent of the source.  

System behavior is undefined when multiple sources define the same global name, and generates log entries when non-equal duplicates are detected.

Api Key Globals

In most cases, your Authentication Provider will make all of the values of the Authentication Token available as Globals (e.g., LoginId), with the possible exception of the Password.

In addition, your Authentication Provider can return a set of Global values.   Typical examples:
  • Scalar values such as UserName
  • Objects such as a database row (e.g., retrieved by LoginId)

Default Authentication Provider Globals

The Default Authentication Provider provides the following variables for an _apikey:
  • user_identifier - e.g, @{_apikey.user_identifier}


Role Globals

As shown below, you can associate Globals with a role.  The Language property indicates how the Global is defined:
  • Sql: code is the valid SQL as part of supplied SELECT returning a row from which you can access attributes as shown below.  Note you might wish to use existing globals in this SQL, such as the LoginId
  • JavaScript: you can supply a JavaScript method, and return a value/object to be used as the Global

Once defined, you can use it in a Permission (think of it as a parameter):




System Globals

These are predefined by Espresso Logic, and are always set for every transaction, referenced in the predicate shown (illustrated above):

 Name  Value  Example
 _apikey  The ApiKey object currently in use  @{_apikey.project_ident}
_project  The Project currently in use  @{_project.name}
_account  The Account currently in use  @{_account.name}