RBAC best practices for effective access management
Modern IAM solutions such as HelloID use Role Based Access Control (RBAC) to organize the issuance and management of accounts and permissions. In larger organizations, it is not feasible to track this for each employee individually. Instead, you define for each role which permissions are needed to perform the associated tasks. Everyone with the same role receives identical permissions. This simplifies access management, enables automated provisioning of permissions, and prevents individual users from receiving incorrect access. In this blog we provide concrete RBAC best practices. First, we briefly summarize the RBAC concept.
The essence of RBAC
RBAC requires a set of unambiguous user data, also called attributes, that are maintained in systems such as HR. Examples include an employee’s job title, the department where they work, work location, and certifications. By connecting the source system with this data to the IAM platform, you can use those attributes to determine a person’s permissions. For example, everyone who is a nurse in the pediatrics department receives the same permissions. Because multiple user attributes can be used and the term role is therefore too narrow, this is also referred to as Attribute Based Access Control (ABAC).
HelloID implements this with business rules that are easy to define, extend, and combine. This also makes it simple to grant permissions at multiple levels. Email, office, and intranet permissions are often generic across the entire organization. There are also often permissions that everyone within a specific department or location receives, regardless of their specific job. Only a subset of permissions is truly tied to individual jobs.
Multiple times per day, your HelloID platform runs a cycle that determines, based on source data and business rules, in which systems someone needs an account and with which permissions. Changes compared to the previous run are then applied in the connected target systems. Target systems range from Active Directory and office applications to a wide variety of organization-specific business systems.
This is the essence, but how do customers use RBAC in practice? We collected several specific examples within our HelloID customer cases of how RBAC has been applied. We start with the basics, then move toward more specific RBAC best practices.
RBAC basic implementation
With HelloID you can start at a very basic level and then expand and refine access management in subsequent projects. In the first rollout, you limit the scope to connecting one source system, usually HR, and one or two target systems with only a few roles. A mid-sized municipality said:
“Thanks to the connection with the HR system, all personnel changes automatically flow into HelloID, which ensures that the correct accounts and access rights are granted. This is not limited to the onboarding of new employees. Job changes are also processed automatically, and when someone leaves the organization, HelloID ensures that the relevant account and access rights are blocked automatically. Role Based Access Control is implemented at a basic level with a defined set of roles. This can be refined later into more specific roles and associated access rights if desired.”
Even with such a basic rollout, the gains are often already significant. Even if automation is limited to issuing accounts and permissions in, for example, Active Directory, IT still gains much more control over access management and reduces manual work.
.webp)
Largest business case with authorization management
The largest benefits are realized when you automate full authorization management for complex business applications. A characteristic example is Electronic Patient Records (EPDs) in hospitals and other care organizations. A mid-sized care organization made a major improvement by automating authorization management for its Nedap Ons care system. Until then, they only provisioned accounts automatically, while permissions were configured manually:
“For each user you must configure their role or roles, their weekly schedule and competency profile, and especially their scope in the system. It is not only about which actions you are allowed to perform but also which client data you must be able to view and edit. This becomes even more complex because many people often have multiple appointments or roles. Similarly, you must be able to configure in a granular way which employee data is accessible to which manager.
Using a person’s department, job title, and competencies, HelloID determines, based on easily configured business rules, which authorizations must be assigned, fully automatically. In this way, every new employee automatically has the correct Ons authorizations at all times. This applies at hiring and also when there are mid-employment changes. Every change in HR data is applied during the next refresh within HelloID and translated to target systems such as Nedap Ons. When someone leaves our organization, all sensitive data is immediately blocked automatically. Overall, automation including Nedap Ons authorization management has saved us about 15 to 20 hours per week, and quality has truly improved.”
Business rules provide an extensive mapping from user attributes in the source system to the authorizations configured within applications. These are not simple permissions. They are often comprehensive two-dimensional combinations of rights:
First, functionality that someone in a particular job may use. A nurse may not prescribe medication, while a physician may.
Second, access to patient data. In the context of the GDPR, caregivers should only access patients within their own department with whom there is a care or treatment relationship. Depending on the job, someone may only view medical data or also modify it.
These authorizations are directly relevant for compliance with information security standards such as NEN 7510. In most cases, Tools4ever provides a standard connector for the specific system. The use of that connector can be configured precisely to support your specific RBAC implementation.
Additional source systems for temporary workers, for example
The earlier RBAC best practices focused on your own employees. Many organizations, however, work with contractors to complete staffing schedules. They often use online broker platforms where the entire hiring process is automated, from search to scheduling.
That is not enough. You want these contractors to participate fully, which requires accounts and access rights. At the same time, many organizations do not want to include temporary staff in the HR system. A solution is to connect such a broker platform directly to your IAM as an additional source system. In the example below, this was implemented at a care organization that uses the Elanza broker platform:
“We want to give contractors access during a shift to systems such as the care system, but with exactly the right permissions. Previously we arranged this in an ad hoc way. We had added a number of contractors who worked many shifts to our HR system, but no account was available for others. As a contractor you then have to ask an internal colleague for help, which creates the risk that people quickly end up sharing accounts. That is obviously unacceptable for NEN 7510 compliance. The solution was the HelloID – Elanza connector. With this, Elanza functions as an extra source system for HelloID. We can now provision contractors with accounts and access rights in much the same way as permanent colleagues.”
For RBAC, you normally use HR attributes to grant the correct permissions. Now the Elanza platform is also connected and passes contractor data and shift schedule data to HelloID, which uses business rules to grant the correct permissions. A contractor may need different rights for each shift. You also want access to be automatically blocked outside scheduled shifts. This is solved as follows:
“Accounts are not torn down each time, but they are automatically deactivated outside shifts. Someone is hired for a specific shift at a certain time, for a specific job and department. Based on that information, HelloID activates the accounts and assigns the appropriate permissions in, for example, Nedap ONS. After the shift, the accounts are deactivated again and rights are withdrawn. At the next shift, other rights are applied, etc. A contractor can therefore start immediately at each shift, while they cannot access our systems between shifts.”
Orchestration of manual processes
We think of RBAC primarily as automated management of digital permissions. You can also use this mechanism to orchestrate many manual tasks. We provide two examples.
Issuance of physical assets
Depending on someone’s role within an organization, an employee may also need a laptop, smartphone, badge, and work clothing. Issuing these items, and reclaiming them when they are no longer needed, is a complex logistics process that is often managed from an IT Service Management system such as TOPdesk. Your IAM platform can orchestrate this. A care organization shared:
“We will also expand our TOPdesk integration. Soon HelloID will automatically instruct TOPdesk to provide new employees with laptops, smartphones, and badges on time, depending on their role. It will also ensure these are reclaimed on time when someone leaves or no longer needs them.”
A safety region also organizes the issuance of devices and clothing for, for example, firefighters in this way. Physical issuance is triggered by service tickets sent to the service management system. You want to generate those tickets automatically based on current user data and events. When does someone join, or when does someone leave the organization. Your IAM platform has that overview and has all the data needed to submit the required tickets on time.
First orchestrate your provisioning, then automate
It is valuable that with HelloID you can automate account and access management step by step. In some organizations, the new IAM platform is first used primarily to orchestrate the provisioning process. They start with automatic notifications from the IAM platform to functional administrators. Those notifications contain the request to create accounts and modify permissions in the relevant systems. Actual automation comes next. A care organization said:
“This is the growth path we wanted. Initially we use HelloID primarily to orchestrate and monitor the entire process. We can then connect more and more target systems to HelloID. Notifications are no longer needed and account and access management becomes fully automated. We are currently planning the rollout of the new integration between HelloID and the Chipsoft HiX Electronic Patient Record (EPD). We first realized orchestration of our account management and are now evolving toward full automation.”
Physical access control with your IAM
RBAC can also be used to better organize physical access control. Today, badges are often managed separately by Facilities Management or a similar department, using a standalone system. That is strange because this management is comparable to digital access management. Access to buildings and rooms often also depends on someone’s job, department, and other attributes.
For that reason, one of the safety regions in the Netherlands included door access in the automation of account and access management:
“Our employees work from different locations, ranging from office locations to fire stations. Each employee receives a personal badge with a registered profile that determines which locations they can and cannot access. We now manage that access through HelloID as well. We already used a management system for this, Paxton. Tools4ever developed a HelloID integration based on the Paxton API, and with it we incorporated the assignment of access profiles into HelloID. This means that, based on someone’s job, department, and contract data, everyone can now be linked to the correct Paxton profile. We keep digital and physical access control in sync.”
The original badge management system remains in use because the physical badges must be configured and activated. IAM orchestrates who is entitled to which access profile.
Temporary roles for preboarding
Many organizations use automated provisioning to ensure that new employees have access to systems on their first day. Digital identities and accounts are usually created before the start date, but they are activated by business rules on the start date. One customer decided to grant access earlier:
“Previously, new employees only received access to IT systems at onboarding. That is a nightmare scenario because everything is new while you simply want to get started on day one. We solved this and now a new colleague gets access to the intranet and systems a month in advance. You can get familiar with the software, email colleagues, complete online training, review shift schedules, and even submit schedule requests in advance.
We still restrict permissions until the day of onboarding because you must not be able to view client data yet. On the day of onboarding, HelloID automatically adjusts the settings and you have full permissions from then on. This is a major improvement, it is much more pleasant for people to start this way and it is a win-win because they are immediately more productive.”
This also shows the importance of business rules that use the contract date and other dates for account and access management. By receiving those data directly from your HR system, for example, you can apply all changes at exactly the right time. Sometimes exactly at the moment of change, and sometimes a few weeks earlier if desired. Organizations also sometimes use temporary roles with limited permissions before the start date, then switch to the actual job on the onboarding day.
Role mining as an RBAC tool
Many organizations start with a defined initial scenario, for example a single source system and Active Directory as the target application. They grow from there. The question is how to develop an initial RBAC model or role model, a first set of business rules that you can refine and expand step by step.
It is usually complex to translate the existing organization and processes into such an initial design. We therefore developed a role mining approach using a form of reverse engineering. The starting point is that under earlier manual management you already tried to provide users with the correct accounts and permissions as well as possible. By reusing that existing data in a smart way, you construct a first role model.
This works as follows. Once you have connected HelloID to a few systems, you can upload the existing settings from those systems. You can analyze these and identify relationships between, on the one hand, the attributes of users in the source system and, on the other hand, existing user accounts and access rights in target systems.
This provides insight into which facilities are normally linked to teams, departments, or jobs. With that insight, an IT administrator and an HR staff member can, together with a Tools4ever consultant, design a first role model in a single session. A customer explained the outcome:
“We did not have a predefined roles and rights structure and were concerned about how to approach this. With a role mining session you combine data from AFAS with existing settings in Active Directory. From that you can distill a first role model. You quickly see which groups of users need similar rights, and you can shape a first rights structure with a manageable set of business rules. With this we automated about 70% of all rights and we can further expand this over time.”
At the same time, that initial role model is not final. You can expand it with new applications and refine the rights structure. Organizations change. Departments merge or split and new jobs are created. A role model is therefore a living structure that you should review regularly and adjust when needed.
That is why we are now building Role Mining functionality into the HelloID governance module. Using pattern recognition, HelloID regularly provides recommendations to optimize your authorization model. This gives you a role mining tool to establish an initial role model and then continue to improve and optimize the model over time.
Want to learn more about using RBAC in HelloID?
In this blog we mentioned several examples of how existing HelloID customers use RBAC and our business rules to organize access management to fit their organization and requirements. If you want to learn more about RBAC in HelloID, you can watch our webinar replay.
Watch the RBAC webinar with live demo