RBAC Tutorial¶

Queries with RBAC¶

Let’s say we have defined the following role in the schema:

CharacterRead:
   description: "Role which can read all Character properties"
   actions: [
     "Character/*/read"
   ]

The user CharacterRead has permissions only over the abstract class Character. When querying, abstract classes permissions are resolved from the lowest concrete class up. The abstract class is constrained to query other classes that are inherited from the abstract class.

Since the properties degree and cybernetics are defined in the concrete classes for Droid and Human, the following request will pass but will contain errors for each field that cannot be read by CharacterRead role.

query allCharacters {
  character {
    name
    __typename
    ... on Droid {
      degree
    }
    ... on Human {
      cybernetics
    }
  }
}

What if the role has permissions to view only Human class and we try to execute a query for Character class?

HumanRead:
   description: "Role which can read all Human properties"
   actions: [
     "Human/*/read"
   ]

query allCharacters {
  character {
    name
    __typename
    ... on Droid {
      degree
    }
    ... on Human {
      cybernetics
    }
  }
}

You will notice that only humans are returned and all other characters have been omitted.

If we try to query Droid with the same role, then we will get an error message stating that we do not have access to this object:

query getDroid {
  droid {
    id
    name
    degree
  }
}

We can be even more specific with the permissions and use filters. Let’s take a look at this role:

HumanFromTatooineRead:
  description: "Role which can read properties of Human with homeworld Tatooine"
  actions: [
    'Human/*/read/(where: {homeworld: {name: {EQ: "Tatooine"}}})',
    'Planet/*/read'
  ]

It will give access only to the Human-s from Tatooine. The permission over Planet are needed in order to retrieve the planet of the Humans-s and make sure the results are correct:

query allHuman {
  human {
    id
    name
    homeworld {
      id
      name
    }
  }
}

Mutations with RBAC¶

Create, update, and delete mutations allow you to perform selections as part of the response.

However, if the role has no read access, the response will ignore the selections.

For example if we have the following role:

PersonWriter:
  description: "Can write People and read their id."
  actions: [
    "Person/*/write",
    "Person/id/read"
  ]

This request will pass but will contain errors for each field that cannot be read by PersonWriter.

mutation createJemRayfield {
  create_Person(objects: [{rdfs_label: {value: "Jem Rayfield"}, birthDate: "2020-01-01"}]) {
    person {
      id
      name
      birthDate
    }
    affected_objects {
      kind
      ids
    }
  }
}

Note the id of the newly created Person. We will be using this id in the examples below.

It is important to note that a role with a property write action cannot delete or set a property to null | []. For example, run the following mutation replacing person_id with the ID of the person we just created in the previous example:

mutation {
  update_Person(
    objects: {
      birthDate: null
    },
  where: {ID: "person_id"})
  {
    person {
      id
    }
    affected_objects {
      kind
      ids
    }
  }
}

The request will be rejected with Unauthorized errors, since setting birthDate to null is effectively deleting the birthDate property. The PersonWriter role actions explicitly states that this role can only write/update this property.

The GraphQL schema may set a property as optional, so you will need RBAC rules to manage controlled removal of such a property by roles with delete access.

If you do not have write permissions assigned and try to perform a mutation, then the mutation will fail and no data will be inserted, updated, or deleted.

ReadOnly:
   description: "Users which can read all Objects and properties"
   actions: [
    "*/*/read"
   ]

mutation createJemRayfield {
  create_Person(objects: [{rdfs_label: {value: "Jem Rayfield"}, birthDate: "2020-01-01"}]) {
    person {
      id
      name
      birthDate
    }
    affected_objects {
      kind
      ids
    }
  }
}

It is important to remember that notActions take precedence over actions. If we have a role such as:

PersonNoDelete:
  description: "Can read and update People."
  actions: [
    "Person/*/*"
  ]
  notActions: [
    "Person/*/delete"
  ]

Then you will not be able to delete objects.

mutation {
  delete_Person (where: {ID: "person_id"}) {
    person {
      id
    }
  }
}

Or remove property values.

mutation {
  update_Person(
    objects: {
      birthDate: null
    },
  where: {ID: "person_id"})
  {
    person {
      id
    }
    affected_objects {
      kind
      ids
    }
  }
}

Filters can be used for mutations as well. To illustrate this, let’s create a second Person:

mutation createGeorgeLucas {
  create_Person(objects: [{rdfs_label: {value: "George Lucas"}, birthDate: "1944-05-14"}]) {
    person {
      id
      name
      birthDate
    }
    affected_objects {
      kind
      ids
    }
  }
}

Note the id of the second person as well.

Now try to delete first “Jem Rayfield” using the following role:

PersonJemAdmin:
  description: "Full permission over Jem Rayfield."
  actions: [
    'Person/*/*/(where: {name: {EQ: "Jem Rayfield"}})'
  ]

In order to do so, replace person_id with the id of Jem:

mutation {
  delete_Person (where: {ID: "person_id"}) {
    person {
      id
    }
    affected_objects {
      kind
      ids
    }
  }
}

The mutation will pass. Now run the same mutation but using the id of “George Lucas”. You will not be able to delete him, as the filter in the action will prevent it.

With the same role, you can try to create a Person with a name different from Jem Rayfield:

mutation createPerson {
   create_Person(objects: [{rdfs_label: {value: "Random Person"}, birthDate: "2020-01-01"}]) {
     person {
       id
     }
   }
 }

You will see that the mutation gets blocked.