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 organization 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 organization 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 organization that covers all the possible combinations without introducing toxic combinations. An issue which, in large organizations 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 organization 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 organization.
Joiners
When a user joins the organization 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 organization. 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 organization 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.
Movers
Quite often users change roles within an organization, 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.