Smart RBAC: Prevent role explosion

In modern IAM solutions, the so-called Role Based Access Model (RBAC) often seems to be the holy grail. For an organisation of any size, it is impractical to keep track of which access rights are required for each individual employee. We therefore look for a smart way to maintain control over access rights management.

RBAC solves this by assigning rights to groups of employees who have the same role and therefore need the same rights. For example, a finance employee is automatically granted access to the accounting software while an IT colleague requires access to specific IT systems. This way, you can automatically grant the correct rights to each employee based on their role. If someone changes roles over time, the IAM platform automatically updates their access rights as well.

Since and individual’s job function or role is always accurately registered in the HR system, it serves as a reliable source system for automating the assignment of access rights. This also prevents the unwanted accumulation of access rights and ensures that departing employees’ accounts are promptly blocked. RBAC helps you stay compliant with privacy and information security standards.

Does that mean Role Based Access Control is the silver bullet for your access rights management? Partly, because there is an important point to consider. If you try to implement RBAC too rigidly, access management can still become needlessly complex, even if roles are thoughtfully structured with role hierarchies and sub-roles. A smart and pragmatic RBAC approach is needed, which we outline in this blog. This way, we can take full advantage of RBAC’s benefits without suffering from its limitations.

Our own vision on RBAC

Within our own HelloID solution, we also use RBAC but we make sure to implement it in a smart, agile way. After all, everyone has their own unique role in an organisation and that is usually only partly defined in someone’s official role. So you should also be able to grant rights based on other attributes. And individual exceptions should not cause problems either.

Prevent role explosion

Often, RBAC is very strictly defined; every employee has a role and each role is assigned a full set of access rights. So if you know someone’s official role (or multiple roles) in the organisation, then you also know what permissions are required.

In practice, you really only find such ‘key roles’ around the primary business processes, the proverbial shop floor. Think, for example, of healthcare staff in healthcare institutions. These are employees with clearly defined job descriptions 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. And because that is also a relatively large group, the return on investment of RBAC is great.

With many other roles, however, things become more challenging. A project manager, for example, obviously needs certain office apps but what other facilities they need can vary from project to project. Likewise, you have junior, medior and senior developers who generally use the same systems, but may have slightly different permissions based on experience, with more senior colleagues sometimes granted a few extra rights. If you attempt to manage these employees strictly by different roles, a role explosion quickly becomes a risk, even if you carefully structure all roles with hierarchies and sub-roles. In practice, you replace the original problem (complex rights management) with another problem (managing a complex role hierarchy).

There is always some debate about the practical usefulness of, for example, sub-roles.

 

From RBAC to ABAC and smart stacking

Within Tools4ever, we therefore deliberately take a ‘broader view’ of RBAC. This starts with the definition of the term ‘role’. Within HelloID, we do not only recognise defined roles and functions. We also want to link access rights to, for example, someone’s department, division, work location, competences or combinations of these. We therefore do not actually use a pure RBAC but a so-called ABAC model (Attribute Based Access Control).

This allows us to manage our access rights much more generically and flexibly. For instance, employees in many organisations – receive an email account, office applications, and internet access on their first day. So it is needlessly complicated to start managing these rights by role. Similarly, it’s also logical that you want to give everyone working in the HR department access to the HR SharePoint site; the specific role of the employee does not matter. We thus take a smart approach to stacking permissions. Many rights are granted organisation-wide or at the level of departments, teams or locations; only if rights are really function-specific, will they be granted on the basis of individual roles. This way, we effectively create a manageable rights pyramid, keeping it as simple as possible by assigning rights at the highest organisational level and only using key roles where it makes sense.

And manage the ‘exceptions’

Moreover, it is undesirable to manage every individual access right by roles or other attributes. Keep room for individual requests. In the example of a project manager, the rights needs vary from project to project and some of the facilities are also only needed during the project. Something similar applies to an IT developer who needs a particular application for a development job. And even if one of the business analysts needs an Adobe licence, it is a waste to give all analysts such an expensive licence by default.

So, accept that you will grant some permissions as custom access upon request. It is important to properly organise the associated management processes. For instance, when a request is made, the right managers and resource owners must automatically assess and approve such a request. So that you maintain control over your access distribution, your licence costs and remain compliant.

Realising that RBAC Vision

For HelloID, we developed a hybrid solution in which permissions can be assigned not only to individual user roles but also to more general attributes, such as an individual’s department, location, or competencies. Within our Provisioning Module, we support this through business rules. We then use Service Automation to also process all individual rights requests in a manageable and controllable way.

Provisioning: Business rules

We automate the assignment and management of access rights using business rules. A business rule is essentially a kind of policy rule consisting of one or more conditions and their associated rights (permissions). Conditions define when and to which users those permissions apply. An example of a business rule we could configure in a healthcare institution:

If an employee has the role ‘Assistant Level 4’ (the condition), they are automatically assigned an EntraID account and an account with the associated role in the Electronic Client File (the corresponding permissions).

For the administrator, the policy-based approach is a huge advantage; you don’t have to delve 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. Nor does it matter if there is overlap between different business rules. This way you can focus on the policy rules and HelloID translates those rules into a consistent, coherent access rights pyramid. The role mining functionality can help to make the rules smarter and simpler, and it keeps your role model up to date. Organisations change all the time and role mining helps to spot mismatches.

You can also include additional policies in these business rules. Take, for example, a rule that an account for a new employee is activated one day before on-boarding, or a requirement that users must accept the terms and conditions before gaining access to applications.

Service Automation

As mentioned, you just need to be able to manually fill in the exceptions in your rights model; the project share for the project manager, the adobe licence for the business analyst, etc. Our rule of thumb is to use business rules to automate about 80 per cent of all accounts and access rights.

The remaining 20 per cent is customised and can be handled with our Service Automation Module. This means that in those individual cases, the employee – or his manager – can submit a request for a specific application or access right himself via the self-service portal. The request is then processed via automated workflows. For example, the system automatically checks whether the applicant meets the criteria, and asks relevant resource owners and managers for online approval. If the request is approved, the access rights are automatically granted. All requests are logged so that every action is traceable for audits. Additionally, temporary approval can be configured so that applications do not remain valid indefinitely.

The benefits of this approach

This approach offers a number of advantages:

• Business rules prevent an explosion of roles and keep our rights management as simple as possible.
• Business rules work intuitively and you can also easily customise your rights model.
• In addition to assigning or revoking access rights, you can include all kinds of other policies.
• The entire approach is auditable, including the processing of individual rights requests.

Want to learn more about how we use RBAC and Service Automation to effortlessly build your access model? Check it out in our webinars.