DEV Community

Cover image for RBAC in Angular and Hyperlambda components
Thomas Hansen
Thomas Hansen

Posted on • Originally published at aista.com

RBAC in Angular and Hyperlambda components

RBAC in Angular and Hyperlambda components is easy to implement. However, as you do, you also dynamically build your Angular UI accordingly. What CRUD verb you've got access to, is actually dynamically determined by reading meta data from your endpoints. The meta data from your web API again, is used to inform the Angular frontend what UI elements it should show. If you for instance have a user that belongs to a role that does not have delete access to one of your CRUD entities, Magic does not render the delete button. This allows you to have a UI that is dynamically built according to access level of individual users using your system.

This has tremendous value for you as a software developer, since you don't have to think about access control in your frontend. In addition, you can create new roles, and/or modify access control to Hyperlambda files, and the frontend will dynamically change accordingly. This idea is often referred to as "RBAC", or "Role Based Access Control", and is the way most sane software systems works, ranging from your Linux desktop, to Kubernetes and web APIs.

In the video below I am demonstrating how RBAC works with Hyperlambda and its generated Angular frontend. If you want to reproduce what I'm doing, you can register a free cloudlet here, and follow me hands on.

Notice, Hyperlambda does not implement group policies. This was a conscious choice to simplify things. Hence there are only two levels of access control in Hyperlambda; Role, and what roles your users belongs to. Since Aista is in the business of simplicity, this makes things easier to understand. Group policies don't really add much as far as we're concerned. The main components in Hyperlambda helping you with RBAC is as follows.

  1. Users - Users belongs to roles
  2. Roles - Roles are associated with endpoints
  3. Endpoints - Endpoints decides which roles can invoke them

This simple pattern gives you complete control over who are allowed to do what in your applications. You might for instance have an "admin" role that is given more permissions than a "normal" user role. This prevents unauthorised modifications and deletions of database records, and is the foundation for any secure HTTP web API.

Top comments (0)