Access Roles

Access Roles

With the introduction of “Open Authentication” the API is taking advantage of the concept of “Roles”. Within the “JSON Web Token” the token issuer can define which endpoints the application can use of the API. The issuer can also determine which database connection strings the application is permitted to use, among “Multiple database connection strings”.

It is the “Payload” part of the “JSON Web Token” which contains the “Roles” element. This is an array of values with one or more items.

The syntax of one item:

<database connection string key> + "." + <endpoint> + "." + <action>

Each item specify which part of the API is permitted to access:

1. The database connection string key.
   1. This is per your configuration in the “application.json” file, “Connections Strings”
      
      
2. The API endpoint.
   1. The value is any of the supported endpoints of the API. Such as “resources”, “activities”, etc.
   2. This also supports the value “all”, meaning all endpoints is accessible.
      
      
3. The API endpoint action.
   1. This value determine which action is permitted on the endpoint. Values could be:
      1. "read" - the application can call GET endpoint.
      2. "edit" - the application can call PATCH endpoint.
      3. "create" - the application can call POST endpoint with action Create.
      4. "delete" - the application can call POST endpoint with action Delete.
      5. "update" - the application can call POST endpoint with action Update.
      6. This also supports the value "all", meaning all actions listed above.

Example:

"roles": [
    "integrationapi.all.read",
    "integrationapi.all.edit",
    "integrationapi.all.create",
    "integrationapi.all.update",
    "default.all.edit",
    "default.all.read",
    "default.all.update",
    "default.resources.create"
  ],