Defining a Schema

The ReBAC schema is comprised of three main components: namespaces, relation definitions, and relations. Namespaces are top-level entities in your application, like documents, folders, and organizations. Relation definitions defines the relationship between namespaces, like a user being a member of an organization. Relations are the actual relationships between entities, like a specific user being a member of a particular organization.

The general flow of defining a schema involves creating namespaces and relation definitions.

An example schema

Download an example schema here.

Breaking down the schema

Getting into the details of how a schema is constructed, we'll start from a top down approach. The first data type we have is the schema.

Schema

The FGASchema holds the full schema/dsl (Domain-Specific Language) for a project.

type FGASchema = {
  dsl: string;
};

Types

Within the FGASchema, we have the dsl field, which starts out with a name and top-level types.

model AuthZ 1.0
 
type user
 
type group

Relations & Permissions

Within each Type, you define Relations and Permissions. These are abstract representations that establish how entities within your model relate to each other and dictate access control logic.

• Relations: Define direct relationships between entities or references to relationships of other entities. They act as building blocks for more complex permission definitions.
• Permissions: Use relations and other permissions to create logical rules for access control, combining simple relationships into sophisticated permission structures.

type group
  relation member: user
  relation super_admin: user
 
type folder
  relation parent: folder
  relation owner: user | group#member
  relation editor: user | group#member
  relation viewer: user | group#member
 
  permission can_create: owner | parent.owner | parent.can_create
  permission can_edit: editor | parent.editor | can_create
  permission can_view: viewer | parent.viewer | can_edit

Full Example

Model AuthZ 1.0

The AuthZ 1.0 model demonstrates a structured and flexible approach to defining access control for a system that includes user, group, folder, and doc entities. By leveraging a combination of relations and permissions, this model establishes a clear and maintainable structure for enforcing authorization policies.

model AuthZ 1.0
 
type user
 
type group
  relation member: user
  relation super_admin: user
 
type folder
  relation parent: folder
  relation owner: user | group#member
  relation editor: user | group#member
  relation viewer: user | group#member
 
  permission can_create: owner | parent.owner | parent.can_create
  permission can_edit: editor | parent.editor | can_create
  permission can_view: viewer|parent.viewer|can_edit
 
type doc
  relation parent: folder
  relation owner: user | group#member
  relation editor: user | group#member
  relation viewer: user | group#member
 
  permission can_create: owner|parent.owner
  permission can_edit: editor | parent.editor & can_create
  permission can_view: (viewer | parent.viewer) - can_edit

Entity Definitions

1. Type user:

   • Represents an individual user within the system. This entity forms the foundation for other relations and permissions.

2. Type group:

   • Represents a collection of users, supporting roles and hierarchies within the group:
     • Relation member: Links users to the group as general members.
     • Relation super_admin: Identifies privileged users within the group who have elevated permissions.

3. Type folder:

   • A hierarchical structure that supports ownership and access control:
     • Relation parent: Establishes a recursive relationship where folders can nest within other folders.
     • Relations for access control:
       • owner: Individuals or group members who have ownership of the folder.
       • editor: Individuals or group members with edit permissions.
       • viewer: Individuals or group members with view permissions.
     • Permissions:
       • can_create: Granted to owner, inherited from parent.owner, or derived from parent.can_create.
       • can_edit: Combines the roles of editor or inherited from parent.editor and includes can_create.
       • can_view: Extends from viewer or parent.viewer and includes can_edit.

4. Type doc:

   • Represents a document, inheriting its structure and access control rules from folder:
     • Relation parent: Links the document to a parent folder.
     • Relations for access control:
       • owner: Individuals or group members who have ownership of the document.
       • editor: Individuals or group members with edit permissions.
       • viewer: Individuals or group members with view permissions.
     • Permissions:
       • can_create: Granted to owner or inherited from parent.owner.
       • can_edit: Combines the roles of editor or inherits from parent.editor and requires can_create.
       • can_view: Includes viewer or parent.viewer, but excludes those with can_edit.

Next

We'll move on to implementing a schema.