​
Introduction RBAC

RBAC simplifies access management by grouping users into roles based on their responsibilities within an organization. This approach eliminates the need for assigning individual permissions to users, making access control more manageable and less error-prone. The system allows precise control over resource access, including individual user permissions and resource-specific access.

​
Permission Types

Permissions in our application are neatly organized into categories that help differentiate between the rights and accessibilities on the backend (server-side operations) and the frontend (user interface interactions). Currently, we have: PermissionType.APP_SERVER This category encompasses permissions that govern actions and operations on the server side. PermissionType.APP_CLIENT This category includes permissions that dictate what elements and interactions are available on the client side, such as in a web or mobile application. While these categories form the foundational structure, they are flexible. Should the need arise for instance, if we have a group of users that interact with a dashboard requiring distinct access rights we can extend these categories. By creating separate types like PermissionType.DASHBOARD_USER, we can ensure tailored access control that is both secure and specific to the roles of different user groups within the application.

​
Differentiating Rolesfor instance

  • Standard Roles: These are the standard roles assigned to users, defining what operations a user can perform within the application. User roles tend to be static but can be adjusted if a user’s responsibilities change.
  • Plan Roles: Tied directly to the subscription tier the user has chosen, these roles determine access to premium or additional features that are not available on basic plans.

​
Roles and Permissions Simplified

In our application, roles and permissions control what users and resources, like projects, can do. Here’s how it works:
  • User Roles: Users have roles that grant them specific permissions.
  • Resource Roles: Projects or services have their own set of permissions independent of users.
When a user interacts with a resource, our system checks two things: 1. Does the user have the necessary permission? 2. Does the resource allow the action the user is trying to perform? This dual check ensures both the user’s and the resource’s permissions align before an action is approved. For details on how roles are assigned to both users and resources, refer to our User Role Assignment. It explains how different types of roles are applied and how they differ when linked directly to a resource instead of a user. In the case of our Permission Guard., it’s designed to verify not only user permissions but also that the resources themselves authorize the interaction during a request.
application.permission.enum.ts
export enum PermissionType {
  APP_SERVER = "APP_SERVER",
  APP_CLIENT = "APP_CLIENT",
}

//! PERMISSIONS DEFINITION

export enum ServerPermission {
  GET_USER_ME = "GET_USER_ME",
  UPDATE_USER_ME = "UPDATE_USER_ME",
  GET_CLIENT_PERMISSIONS = "GET_CLIENT_PERMISSIONS",
}

export enum ClientPermission {
  USER_PROFILE_MENU = "USER_PROFILE_MENU",
}

//! USERS - ROLES / PERMISSIONS ASSIGNMENT

export const userServerPermission = [
  ServerPermission.GET_USER_ME,
  ServerPermission.UPDATE_USER_ME,
  ServerPermission.GET_CLIENT_PERMISSIONS,
];

export const userClientPermission = [ClientPermission.USER_PROFILE_MENU];

//! PLANS - ROLES / PERMISSIONS ASSIGNMENT

export const examplePlanServerPermission = [
  ServerPermission.GET_USER_ME,
  ServerPermission.UPDATE_USER_ME,
  ServerPermission.GET_CLIENT_PERMISSIONS,
];

export const examplePlanClientPermission = [ClientPermission.USER_PROFILE_MENU];