5. Access Control

Starbug implements a Role Based Access Control (RBAC) system. This is based on system of grants called permits. These are stored in the permits table.

Groups, Statuses, and Ownership

All entities within Starbug have these fields:

Field	Description
owner	The owner field references a user ID to indicate that users ownership of the record.
statuses	The statuses field references the statuses taxonomy. Each record can have a status such as published or deleted.
groups	Groups is a multiple reference to the groups taxonomy. Each record can have one or more groups.

Permits

Permits are the rules that govern access control. The permits utilize groups, ownership, and statuses to grant different types of access. Let's look at the different components of a permit.

Field	Description
model	The model
action	The action. This will be the name of a function such as create or delete. It can also be read
role	The role that this applies to. See roles below
priv_type	This can table, global, or % (any). If you are acting on a specific record, you need global permits. Otherwise, you need table permits.
object_statuses	You would use this field to restrict the status. For example, if you want to create a permit that applies to published content.
user_groups	You would use this field to apply this permit to a specific group of users

Roles

Role	Description
everyone	This means everyone. If you set user_groups, it's everyone within the group
owner	The owner role is fulfilled when a users id is in the owner field of the target record or records
self	This would only apply to a user operating on themselves. For example, doing an update_profile
groups	This would apply between users and objects that share the same groups

Model and action

Permits are granted by model and action. For example, you might grant access to the users::login function. It's important to note that you can call these actions independently of the URL you are visiting.

Type (priv_type)

Possible options are table, and global. Table applies to the table like directory permissions such as creating an entry. Global applies to records within the table and can be used for actions that relate to specific objects (edit, delete). The type of permit that is looked for is based on whether or not an id is included in the POST data.

Defining a permit

Permits are defined in migrations, and follow the below structure:

$this->permit("[model]::[action]",
 "[role]  [option]:[value]  [option]:[value]"
);

Examples

This is what the login permit looks like.

$this->permit("users::login",
  "everyone  priv_type:table"
);

The POST data might look like this:

{
  "action[users]":"login",
  "users[email]":"[email protected]",
  "users[password]":"weakpassword"
}

The update profile permit:

$this->permit("users::update_profile",
  "self  priv_type:global"
);

The priv_type is global and the POST data includes an id:

{
  "action[users]":"update_profile",
  "users[id]":"5",
  "users[first_name]":"Ali",
  "users[last_name]":"Gangji"
}

This single permit controls access to view published content.

$this->permit("uris::read",
  "groups  priv_type:global  object_statuses:published"
);

In other words, if you want to restrict a uris entry to admin users, apply the admin group to that record.