RBAC

Note

With Kilpi, you don’t have to decide between RBAC, ABAC, ReBAC or other access control models. Kilpi allows fluidly mixing them together based on your needs with a single declarative API. Besides, RBAC, ABAC and ReBAC are not completely separate models (e.g. RBAC is a subset of ABAC).

This guide is a tutorial on how to implement authorization policies that would fall under the term of RBAC.

Tip

Before implementing RBAC, carefully consider whether ABAC or a Permissions Based System would be more suitable for your use case as RBAC is often a simplistic approach.

Furthermore, implementing permissions instead of roles may allow for a more flexible authorization system, if needed. Roles can be seen as a user-facing abstraction of permissions, instead of an attribute of the user.

Implementing a role-based access control with Kilpi is simple with the createRbacPolicy utility, which is an alternative policy constructor API.

export const rbacPolicy = createRbacPolicy(
  (subject: Subject | null) => { // May optionally be async, and e.g. fetch data
    if (!subject) return null; // Subject narrowing
    return {
      subject,
      roles: subject.roles, // Return user's roles as string[]
    }
  }
)

The rbacPolicy constructor can now be used to easily create RBAC policies with strong typesafety.

export const policies = {
  documents: {
    read: rbacPolicy("user", "admin", "guest"),
    create: rbacPolicy("user", "admin"),
    delete: rbacPolicy("admin"),
  },
}

Due to how the Policy API was designed, the RBAC configuration has to be declared as “Action-to-Roles” instead of “Roles-to-Actions”.

We believe this is justified, as most authorization systems quickly run into limitations with RBAC. Let’s imagine a new requirement, where documents can be deleted by admins, but also by users if the user created the document. With this API, breaking out of the RBAC model to ABAC is trivial:

export const policies = {
  documents: {
    read: rbacPolicy("user", "admin", "guest"),
    create: rbacPolicy("user", "admin"),
    delete: rbacPolicy("admin"),
    delete((user, document: Document) {
      return user && (hasRole(user, "admin") || user.id === document.ownerId) ? grant(user) : deny()
    })
  },
}

 function hasRole(subject: Subject, ...roles: Role[]) {
   return roles.some(role => subject.roles.includes(role));
 }

With an “Roles-to-Actions” API, migrating to ABAC would require a more complex refactoring.