Demo API Security

In this example, we want to define a SalesRep role that provides fine-grained access control to purchaseorders:
  • filters purchaseorders for the current Sales Rep (applies to Sales Reps only)
  • disables update access to the paid attribute

Background - row filtering based on "user" table values

The employee object shown here has a unique key on login.  We want to be able to use the employee values to filter rows in other tables.  In this example, we want to filter purchaseorders whose salesep_id matches the employee_id of the currently logged in employee.



Row Filtering

We implement row filtering as described in the subsections below.

Define SalesRep role, associate employee row using Global

We want our security to apply only to SalesReps.  So, we define a role as shown below.

Importantly, we also define a Global named SalesRepContext that selects the desired employee row, using the current users login credentials (_apikey.user_identifier).  Required means a throw an error if a row is not found.


Define Table Filter using Global value

Next, we use this global in the Permissions for table purchaseorder.  Note how the predicate refers to the Global using the @{<globalName>.<globalAttribute>} syntax.  In this case, the attribute is the employee_id from the employee row obtain as described above.

This predicate is then automatically merged into all Resources defined for purchaseorder when access by users assigned to the SalesRep role.  You can also use such global-parameterized filters for a specific Resource.



Column Access Permissions

Note that the Access Types in the diagram above do not include update.  We authorize update by defining an additional Permission as shown below, omitting the paid column: