Skip to content
back to achievements

Case study · LookSuite

Client project · AugmentProject period2025 – Present

Role-based access control

Implemented Role Based Access Control (RBAC) to enforce precise user permissions, dynamically allowing or restricting actions and features based on user roles.

01

Why

LookSuite is used at different levels of an organization, and each level needs its own control over how the application behaves. A person using the app, a group, a department, an organization and a whole tenant should not all have the same power, and each should have its own setup, configuration and features. Access had to depend on the role, not be the same for everyone.

02

Decision

I built role-based access control with levels that follow the structure of the customer: tenant, organization, department, group and user. Each level has its own setup, configuration and features. The role a person holds decides which features and actions they can use. The backend enforces it, so a restricted action is refused whatever the client shows. The application also shows or hides functionality by role. Authentication runs through Keycloak, which gives each tenant its own identity provider.

A permission matrix lists which actions each role can and cannot do, and it is the single reference for what is allowed.

Because every new feature has to behave correctly at every level, each feature is tested against the different levels before it ships.

How it fits

Hover or focus a box for the story behind it.

Five levels, tenant, organization, department, group and user, each with its own setup. Every action is checked against a permission matrix in the backend, and a role change revokes the token so the person signs in again.LevelsA requestA role changesThe top level. Each tenant has its own identity provider through Keycloak.Tenant Top levelEach level has its own setup, configuration and features.Organization Own setupEach level has its own setup, configuration and features.Department Own setupEach level has its own setup, configuration and features.Group Own setupDown to the individual user: the role a person holds decides which features and actions they can use.User Own featuresA person tries to use a feature or run an action.User action Open a featureThe application shows or hides functionality by role, and checks the role on its side too.Application Shows by roleThe backend checks the role against the permission matrix on every action. The matrix lists which actions each role can and cannot do.Backend Checks the matrixThe role is allowed to do this, so the action goes through.Allowed Role has accessThe role is not allowed, so the backend refuses the action even if the client was tampered with.Refused Whatever the UIA person's role is changed.Role changed In the systemTheir token is revoked, so the old access stops at once.Token revoked Old access endsThey sign in again, and the new role applies from then on.Sign in again New role applies

Access follows the structure of the customer: tenant, organization, department, group and user, each with its own setup, configuration and features.

03

What I built

Implemented Role-Based Access Control (RBAC) to enforce user permissions and dynamically determine which functionality and actions are available based on assigned roles.

04

Trade-offs

  • Every new feature needs a decision about which levels get it. A permission matrix lists which actions each role can and cannot do, so the answer is quick to look up, but it still has to be made each time.
  • A role change means signing in again. When someone's role changes, their token is revoked, so they have to log in again for the change to apply. That is the price of making sure old access doesn't linger.
  • Roles are fixed, not custom. I chose fixed roles to keep the complexity down. Custom roles are planned for later. With custom roles it becomes hard to answer "what can this person actually do?", so they need proper debugging tools and a proper setup first.

05

Outcome

The right features and actions are available to each level, and the others are restricted. Configuration lives at the level where it belongs instead of being global.

Technologies