Skip to main content

Object Model for Roles

The Entitlements System has pre-built snippets that can be used to enforce role-based access control without authoring in Rego. These snippets depend on the object model to define role and role bindings.

A role defines a set of permissions over resources. A permission is the set of actions permissible over a set of resources.

For example, a single role with an identifier id is defined as:

{
"id": {
// allow grants access to resources selected by include and not selected by the exclude selectors
"allow": {
"include": [{
"actions": ["action-id"],
"resources": ["glob/*/selector", "resource-id"]
}],
"exclude": [{
"actions": ["action-id"],
"resources": ["*", "resource-id"]
}]
},

// deny removes access to resources allowed by any roles
"deny": {
"include": [{
"actions": ["action-id"],
"resources": ["**"]
}],
"exclude": [{
"actions": ["action-id"],
"resources": ["resource-id"]
}]
}
}
}

Using this definition, roles provide a convenient way to express allow or deny lists over action/resource combinations. By default, roles do not grant any permissions. They need a role binding to be associated with subjects.

Role binding attaches a role to a set of subjects. Role bindings can be expressed by subject IDs, subject attributes, or both.

For example, the following associates the role with id role-id with all subjects who have the attribute attribute-id with value value. It also associates role-id with the subjects user-id and group-id.

{
"role-id": {
"subjects": {
"attributes": {
"attribute-id": "value",
},
"ids": ["user-id", "group-id"]
}
}
}

When subjects are selected by both attribute and ID, the union of subjects matching those selectors are bound to the given role.