Getting started

Access Control is an elaborate system to grant or deny users access to certain Plate functionalities. It works by creating and managing so called ‘policies'. A single policy or multiple policies always belong to a single Role, which describes a certain ability or inability for the assigned users, when they’re working with Plate functionalities.

This page explains the terminology of Access Control.

Policy

A Policy is a set of rules which allows or denies certain actions to certain resources, based on certain conditions. A policy always consists of the following elements:

Version - version number, current version is 1.
Statement - the policy statement, which contains the actual policy magic.

The statement block contains of:

Effect - whether the policy denies or allows the action. Value can be deny or allow.
Action - which action is this policy for. For example read, create, update, delete, etc. Go to the Actions page to learn more.
Resource - the Plate functionality names that the policy is about. E.g. attachments, or content types. These functionality names are notated in PlateID format. Go to the Resources page to learn more.
Condition - the conditions under which the policy takes effect. For example, the policy only takes effect if the site_id of the resource in question is equal to 1234. Go to the Conditions page to learn more.

Policies are notated as JSON. Check out an example:

{
  "version": 1,
  "statement": {
    "effect": "allow",
    "action": "create",
    "resource": "plateid://Base/Attachment",
    "condition": {
      "number": {
        "==": {"object.site_id": 1234}
      }
      "string": {
        "==": {"subject.email": "test@email.com"}
      }
    }
  }
}

Only allow editing posts of a specific Post Type:

{
  "version": 1,
  "statement": {
    "effect": "allow",
    "action": "create",
    "resource": "plateid://Content/Post/",
    "condition": {
      "number": {
        "==": {
          "object.site_id": 1234
          "object.post_type_id": 456  
        }
      }
    }
  }
}

Role

A role consists of a single policy or multiple policies. All the policies in the Role together act as a bundle of access control rules. The role describes the actions an assigned user can or cannot take, and is assigned to a user through a group or directly.

Example names for a Role: “Access to blog posts”, or “Blocking form messages”.

Group

A group is a set of roles, that can collectively be assigned to a user. A group usually suggests a certain level that a user can have, which comes with a set of clearances. A group typically says something about who you are, and less about what you are able to do.

Example names for a Group: “Administrators”, or “Content editors“

Strategy

The strategy is the way all assigned policy rules are evaluated, when access is requested by a user. At this moment the only available strategy is: “Deny overrides Allow“, which means:

Evaluate all applicable policies with effect ‘Deny’ for the user in question.
- when there is match: deny access
- when there is no match: evaluate all policies with effect Allow
  - when there is a match: grant access
  - when there is still no match: deny access