NodeJS comes into its own when developers choose to utilize development environments that provide native support, right out of the box, like amplication.com, for example. These top-tier environments often provide code completion and dashboard-based security configuration.
To maintain the security of a web application, controls need to exist that allow developers to specify permissions and delegate access where necessary. NodeJS has two main methods of achieving this.
NodeJS Role-based Access control
Role-Based Access Control (RBAC) is an access control method native to the NodeJS ecosystem. RBAC is derived from the traditional definition of user roles in access control. By defining roles, administrators can decide what level of access each role should have.
Security administrators grant users permissions by role rather than individually to save administrative time during user creation. Administrators can clearly define and monitor access to resources at scale. By limiting a user’s access to online resources to the bare minimum required to complete their job, the principle of least privilege can be enforced.
User accounts are assigned to roles and the accounts inherit the implied security detailed by the role. When a user wants to perform a specific action, a check is done on the application database to verify whether the user is allowed to act based on their role.
NodeJS Attribute-based Access Control
Attribute-based Access Control (ABAC) on the other hand utilizes defining factors inherent to the user requesting access. ABAC is regarded as a next-generation technology utilized by NodeJS. It grants users access to resources based on who they are.
By utilizing complex user attributes such as username, location, and even attributes from connected systems such as a security clearance, for example. User access can be controlled with attributes that are not referenced from an existing data store either. These attributes could be environmental attributes such as time of access or access location.
Control can also be exercised by utilizing attributes of the resource being accessed. Examples of this are file modification dates, data confidentiality, etc.
ABAC is ultimately, much more flexible than RBAC, allowing security administrators as much or as little granulation as is required to keep client and business information safe from unwanted threat actors. This practice is also encouraged for systems that are only accessible to employees within an organization as it adds a layer of security to prevent insider threats.
RBAC vs ABAC
While RBAC could be considered as a form of access control that is primitive to ABAC, it still has a place in the orchestration of modern security.
RBAC is typically configured before ABAC when a combination of the two is implemented. This builds a base for security control, which is like the security stack utilized by cloud service providers. Adding ABAC on top of RBAC can add additional complexity to access requirements. It should be noted, however, that combining these mechanisms requires additional server-side memory and processing time, and should be done only when necessary. Online processing time does, after all, translate directly into overhead costs when it comes to hosting services.
Careful and decisive planning is needed at the start of the project to align the internal structure of the environment with the security schema that is going to be implemented. When RBAC and ABAC are combined, broad access can be initially granted by RBAC, and access can then be powerfully filtered by ABAC. This entails that the web application would first utilize RBAC to establish who has access to a resource and afterward ABAC is used to establish what the user can do with the resource and when they may access it.