Authorization

Introduction#

Authorization is one of the key components to keeping data safe and restricted from unwanted use. Therefore, Architect comes with pretty flexible but precise authorization mechanism allowing you to construct your rules on the fly.

Roles#

Roles are defined in a simply passing the name of your role to the user account creation or update flow. From that point, that role name can be used to construct policies and scopes for your data collections and entities.

Assigning a role#

Updating a role#

Role manipulation restrictions#

Only users with admin role can update roles for other users.

Authorization Management#

Authorization is defined through a single JSON object containing policy and scope definition. Policies and scope are tied to each table with no predefined values to start with and are specified through Architect Dashboard.

Scopes define the set of entities that user has access to.

Policies define the conditions for users to comply with while creating, modifying or deleting an entity.

Here is an example of a policy and scope definition:

Example policy/scope definition

{
  "entities": "todos",
  "scope": {
    "regular": "{ user_id: current_user.id }"
  },
  "create": "true",
  "update": "current_user.id == record.user_id",
  "delete": "current_user.role == 'superuser'"
}

Policies#

Updating policies is done via Dashboard by updating one or more of the available fields: create, update, show, delete, corresponding to the entity actions that Architect provides.

Let's say our todo entities have a user_id field representing ID of the user that created the todo task. Our policies could look something like this:

{
  "create": "true",
  "update": "record.user_id == current_user.id",
  "show": "true",
  "delete": "current_user.role == 'superuser'"
}

A policy definition like this ensures that everyone can create and view a todo, only the creator can update it, and only a user with the 'superuser' role can delete it.

Scopes#

Updating scopes is also available through Dashboard. It is done by adding filters for every possible user role.

{
  "scope": {
    "regular": "{ user_id: current_user.id }",
    "superuser": "{}"
  }
}

A scope definition like this ensures that regular users can list only the todos they created, while superusers can list all todos.