RBAC is the idea of assigning system access to users based on their role within an organization. The system needs of a given workforce are analyzed, with users grouped into roles based on common job responsibilities and system access needs. Access is then assigned to each person based strictly on their role assignment. With tight adherence to access requirements established for each role, access management becomes much easier. With the proper implementation of RBAC, the assignment of access rights becomes systematic and repeatable. Further, it is much easier to audit user rights, and to correct any issues identified. RBAC may sound intimidating, but it can in reality be easy to implement, and will make the ongoing management of access rights much easier and more secure. https://www.csoonline.com/article/3060780/5-steps-to-simple-role-based-access-control.html
An example may be someone who works in HR could be an ‘admin’ for employee files, so they are the ones who would have permission over creating/updating/deleting those particular files, while the department head might only have ‘manager’ access to those, being able to only view or modify.
If authentication is the process of verifying and confirming a user’s identity (“you are who you say you are”), authorization, is the process of granting or denying access rights and permissions to authenticated users based on their identity and assigned privileges.
Three primary rules are defined for RBAC:
- Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
- Role authorization: A subject’s active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
- Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized. https://en.wikipedia.org/wiki/Role-based_access_control
RBAC is like having different roles assigned to people in a country club. Each role determines what they can access and do. For example, the Club Manager has full control, members have limited access, and guests have restricted privileges. RBAC ensures that everyone has the right permissions based on their role, maintaining order and security in the clubhouse.
Access rights are granted to the roll, as the user may change departments or even leave the company.
Authentication
An easy example would be limiting the access to things having to do with payroll, since there is a lot of sensitive information in that department. There’s no reason an engineer or a janitor or a security guard would need access to that information, but I sure bet the people in the payroll department do!
I’m curious to see how the middleware is going to filter through the access privlidges.