Without well-defined automated processes, HR and IT departments often struggle efficiently managing an employee’s lifecycle.

At ProofID we take a simple yet effective stance to identity lifecycle management. If you follow and implement our recommendations you’ll immediately improve your security posture with the added benefit of increased productivity.

What is Role-Based Access Control (RBAC)

Role-based access control (RBAC) is an identity management approach that assigns and authorises access to resources and information to users within your organisation based on their role.

These roles are assigned to users based on a number of factors such as the user’s job function within your organisation or third parties such as customers and business partners.

For RBAC to work efficiently it is important to define a set of roles that aligns with the business, the user populations, the resources available as well as defining the rules for users to be assigned to a role. These tasks are normally referred to as “role modelling”.

Once a role model is defined, access to resources and information is assigned to each user based on that role. Once you have achieved tight adherence to access requirements established for each role, access management becomes much easier, more controlled and regulated.

The challenge with implementing RBAC is defining a role model for your organisation that covers all the possible combinations without introducing toxic combinations. An issue which, in large organisations particularly, can become a project in itself.

Modern RBAC and our approach

However, there is another way. A more “simplified” role model is available which retains all the benefits and advantages of RBAC, but delivers it in a shorter time frame. This method divides roles into three main categories:

  • Birthright Roles: Based on the highest classification of users such as employee, contractor or partner.
  • Business Roles: Based on a department or job function (e.g. HR, Account Executive, Account Manager, Operations Manager, IT Administrator etc.). These roles are normally associated with a set of resources that are relevant to that specific role function. For example, granting access to a CRM platform rather than a HR system.
  • Optional Roles: These roles are normally not assigned based on the user profile but rather on requests from either the user themselves or by another user (e.g. a Project Manager) on their behalf (e.g. Project No xyz member, Temporary Reviewer, etc.). These roles are associated with resources needed to potentially any user but without an easy to describe rule. For example, users assigned to a specific project, or users who are temporary assigned to a task or a working group. Optional Roles requested by the user, or by someone else on their behalf, often require approval by one or more administrators before being granted.

By working within this principle, any organisation can then adopt a successful user provisioning service for all Joiners, Movers and Leaver’s. Below are some examples of each and the benefits of adopting the RBAC model to your organisation.


When a user joins the organisation a HR record is created, and a role granted for the new starter. This would trigger the automation, of the creation, of the birthright resources and access for the user’s role within the organisation. A simple automated workflow joining HR and IT.

Birthright and Business Roles and resources are normally assigned automatically to users depending on information that originates in an authoritative source such as the HR system.

In this example, birthright roles and resources are assigned when a user joins the organisation and will be granted access to a set of resources based on their defined role; examples of resources that are normally classified as birthright are the employee badge, an account in Active Directory, email account, access to the corporate intranet and so forth.


Quite often users change roles within an organisation, bringing with them access to resources they no longer need.

For example, an IT support engineer may change roles or be promoted, let’s say, to an internal IT Administrator. In their current support role, they have access to the support portal and remote access to other business partners systems. In their new role, they may not require this access anymore as he is purely an internal IT Administrator.  By defining these two roles, as ‘Support Engineer’ and ‘IT Administrator’, in the RBAC model, the user can be moved to the IT Administrator role while the Support Engineer role is removed, revoking access to previously allowed systems.


When a user leaves, access to all systems should be revoked at the end of their final day. By adopting a RBAC model, this can be a simple task, enabling you to disable the account and access to systems based on their previous role.

However, if the organisation has not yet implemented the RBAC model, this can become problematic. Organisations, invariably, have little idea about any user’s previously accumulated access. Take our example of the Support Engineer. If there was no RBAC in place, the Support Engineer would have added IT Administrator privileges to their access, they could have requested additional access. Or, as an IT Administrator, granted it to themselves as optional roles. Access may be revoked for their last current role but not for the previously granted Support resources and remote access to their business partners systems or additional accesses.

Role Driven Lifecycle Management Joiner/Mover/Leaver Process

Keeping control

In a classic RBAC model, access is strictly controlled by a role and this makes it relatively easy to have an accurate picture of who has access and to what. However, how do you deny users access that they should no longer have?

A recommended approach, and one favoured by auditors, is to schedule periodic access reviews or re-certification campaigns. Here, administrators are able to review each user and confirm or remediate which resources the user has access to or even disable the user account.

In addition to keeping users’ access to a minimum, reviews offer auditor reports with up-to-date resource access for each user.

In summary

Implementing RBAC does not need to be a lengthy and difficult project. Organisations that follow recommended  practices, that use identity, governance and administration software and depend on RBAC, are better equipped to secure their sensitive data and critical applications.

Implementation can be achieved with limited disruption, enabling users to remain productive from day one, with access to email and other systems. Users can change roles safely without building and gaining unrequired access and can then be successfully de-provisioned once they leave.

Learn more and see how the employees can be quickly and securely onboarded in the first in our series of video demos Securing & Automating the Joiner, Leaver, Mover Process with ideiio.

Blog sign-up


Latest from twitter

Written by Sergio Benis, Pre-Sales Director – ProofID

Sergio has worked in Identity and Access Management for 20 years and has implemented many projects with leading technologies in the IAM space. Covering both delivery and pre-sales roles, he has been involved in the full ecosystem of many IAM projects. In recent years, Sergio has been a Solution Architect at Ping Identity and has, since 2019, headed up the ProofID Technical Pre-sales team.