Smart RBAC: prevent role explosion
In modern IAM solutions, the so-called Role Based Access Control model (RBAC) is often seen as the gold standard. In any organization of scale, it is impractical to track which access rights are needed per employee. We therefore look for a smart way to maintain control over access rights management.
RBAC addresses this by granting rights to groups of employees who share the same role and therefore need the same access. For example, a finance staff member receives default access to the accounting software, while an IT colleague needs access to specific IT systems. This allows you to automatically assign the correct rights to each employee based on their role. If someone later assumes a different role, the IAM platform automatically updates the rights as well.
Because an employee’s job or role is always recorded accurately in the HR system, that system serves as a reliable source to automate the issuance of access rights. This also prevents undesired accumulation of rights and ensures that the accounts of departing staff are blocked in time. RBAC helps you remain compliant with privacy and information security standards.
So is Role Based Access Control the definitive solution for access management? Partly, because there is an important consideration. If you try to implement RBAC too rigidly, access management still becomes needlessly complex; even if roles are structured intelligently with, for example, a role hierarchy and subroles. A smart and pragmatic RBAC approach is needed and we outline it in this blog. This ensures that we gain the benefits of RBAC without the limitations.
Our perspective on RBAC
Within our own HelloID solution we also use RBAC, but we ensure a smart, adaptable implementation. Everyone has a unique role in an organization and that is usually captured only partly in an official role. You must therefore be able to grant rights based on other attributes. Individual exceptions should not cause problems either.
Prevent role explosion
RBAC is often defined very strictly; each employee has a role and each role has a complete set of access rights assigned. If you know someone’s official role, or multiple roles, you also know which rights are required.
In practice, you only find such key roles around the primary business processes, the proverbial front line. Consider clinical staff in healthcare organizations. These are employees with a clearly defined job description who all use the same systems and data. In that case, RBAC allows you to easily issue and manage accounts and user rights for all those employees. Since this is also a relatively large group, the return on RBAC is high.
For many other roles this is much more challenging. A project manager, for example, obviously needs some office apps, but the additional facilities required can vary by project. You also have junior, mid-level, and senior developers who largely use the same systems, while more experienced colleagues sometimes receive slightly broader rights. If you try to manage such employees using different roles, a role explosion looms quickly, even if you structure all roles well with a role hierarchy and subroles. In practice, you replace the original problem, complex rights management, with another problem, managing a complex role hierarchy.
In any case, the practical value of subroles is debatable.
From RBAC to ABAC and smart layering
At Tools4ever we therefore deliberately apply a broader view of RBAC. That starts with the definition of the term role. Within HelloID we recognize not only defined roles and job functions. We also want to link access rights to an employee’s department, division, work location, competencies, or combinations of these. In practice we therefore do not apply a pure RBAC model but an ABAC model, Attribute Based Access Control.
This allows us to manage access rights more generically and more flexibly. In many organizations, regardless of role, employees receive a mail account, office applications, and internet access on the day of onboarding. Managing these rights per role is needlessly complex. It is also logical that everyone working in HR is granted access to the HR SharePoint site; the specific role of the employee does not matter. We therefore stack rights in a smart way. Many rights are granted organization-wide or at the department, team, or location level; only when rights are truly function-specific do you assign them based on individual roles. In effect, we build a manageable rights pyramid that you keep as simple as possible by defining rights as high as possible in the organization and using key roles only where helpful.
And manage the exceptions
It is also undesirable to manage every access right solely through roles or other attributes. Leave room for individual requests. In the project manager example, required rights vary per project and part of the facilities are needed only during the project. Something similar applies to an IT developer who needs a specific application for a development task. Even if one of the business analysts needs an Adobe license, it would be wasteful to assign such an expensive license to all analysts by default.
Accept that a portion of rights will be provided as custom, on-request access. It is then important to organize the associated management processes properly. When a request is submitted, the correct managers and resource owners must automatically review and approve it. This allows you to maintain control over access issuance, license costs, and compliance.
Implementing this RBAC vision?
For HelloID we developed a blended solution where rights can be assigned not only to individual user roles, but also to more general attributes such as department, location, or competencies. In our Provisioning Module we support this with business rules. We then use Service Automation to process all individual access requests in a manageable and controlled way.
Provisioning: Business rules
We automate the issuance and management of access rights using business rules. A business rule is effectively a policy that consists of one or more conditions and the associated rights, permissions. Conditions determine when and for which users those permissions apply. An example of a business rule as we can configure it in a healthcare organization:
If an employee has the job title “Care Assistant Level 4” (the condition), they receive by default an EntraID account plus an account with the associated role in the Electronic Client Record (the associated permissions).
For the administrator, thinking in policies is a major advantage; you do not need to dive into the underlying technical structure of roles, attributes, and rights. You can easily add rules that can apply to all users, specific departments, roles, or other attributes. It also does not matter if there is overlap between different business rules. You can focus on the policies and HelloID translates those rules into a consistent, coherent rights pyramid. Role mining functionality helps make the rules smarter and simpler. It also helps keep your role model current, because organizations change continuously and role mining helps identify mismatches.
You can also include additional policies in these business rules. For example, a rule that an account for a new employee is activated one day before onboarding. Or the requirement that users only gain access to applications after they have accepted the terms and conditions.
Service Automation
As noted, you must be able to handle exceptions in your access model manually; the project share for the project manager, the Adobe license for the business analyst, and so on. Our rule of thumb is that business rules can automate about 80 percent of all accounts and access rights.
The remaining 20 percent is custom and is handled with our Service Automation Module. In those individual cases the employee, or their manager, can submit a request for a specific application or access right via the self-service portal. The request is then processed through automated workflows. The system automatically checks whether the requester meets the criteria and it automatically asks the relevant resource owners and managers online for approval. If the request is approved, the access rights are granted automatically. All requests are recorded so that every action is traceable for audits. You can also configure temporary approvals so that requests do not remain valid indefinitely.
The benefits of this approach
This approach delivers several benefits:
Business rules prevent a role explosion and keep access management as simple as possible.
Business rules are intuitive and you can also adjust your access model easily.
In addition to granting or revoking access rights, you can include various other policies.
The entire approach is auditable, including the processing of individual access requests.
Want to learn more about how we use RBAC and Service Automation to easily design your access model? See it in our webinar.