You Shall Not Pass
Role based access control is a policy access control defined around roles and permissions.
In the early stage of the design for your web application and in case you are planning to enable authentication you may consider to implement roles-based-authorization mechanism to control what will be displayed to the end-user and what would be enabled or disabled according to pre-defined set of rules.
In the following, I am going to show you a simple approach how it can be done with minimal coding, We want to make sure that this mechanism will be standalone and maintainable by the development team and the business operations if need.
The idea behind the Role-Based-Authroization mechanism is to wrap single-child component with the rule so the wrapper will augment the children according to the pre-defined set of rules.
The Rules
The mechanism of the RBA component need to work with pre-defined rules, those rules can be defined as constant in your web application or can be pulled from a web-server via REST call.
The rules are built from key-value pairs, the key is represented as the id and the value as the action so the RBA component will decide if to hide the child component or just disabled it.
The permission should be stored in our redux-store to enable the RBA container to be aware for those permissions, with this approach, we can fetch rules on-demand and disptach them to the system and the UI will be rendered automatically.
When we want to update the system with the new permissions, we need to dispatch the SET_RBA_DATA action to initialise the permissions.
The Process
Once we wrapped the child component with our container the augmentation process being.
The first activity is to apply the rules, In this method there is a check for the action of the permission by taking the permission id that being passed as property to the RBAC container. The actions are configurable according to your requirements.
By default, when we augment a child, we will clone the element using React and add the relevant attribute, if its disable, we will add the disabled attribute, for example, we can use it for inputs. If the action is HIDDEN, we will return null, In such case, there is no need to clone the element.
Once we finish to augment the child, we will wrap the child with the external element and notate it the permission id — this will enable us to maintain it and debug it.
Let’s debug it.
In the video you probably noticed that I am dispatching custom permissions object to the system to modify my view, with this approach you can enable business operations to define their own rules and your web application will consume those rules from external resource.
Wrapping Up
This article should give you what is the right approach to integrate Roles-Based-Authorization mechanism for your web application and how to utilise them for providing the best architecture to your app.
Who am I?
I am Ofir Attia, a Web developer, focusing on design and architecture. Currently working at Amdocs as Software Architect.
Contributing
Special thanks to my co-worker Refael Oknin, Refael and I develop open-source libraries together for the past 2 years.
the RBA feature comes as part of the harmony-boilerplate that we developed.
Want to know more about Harmony? read the following article.
