What is Role Based Access Control (RBAC)?  

 

Role Based Access Control is the process of mapping access permissions to organizational 

roles, essentially to define what an individual is allowed to have access to if they have a 

particular role or roles within the organization. 

 

RBAC is important when designing an IGA implementation, as it enables you to make sense 

of all of the varied access requirements across the organization and prevent access from being 

a ‘free for all’. 

 

 

 

Let’s consider for a moment what happens in a scenario where there are no roles defined. 

When a request for a new account comes in, the person creating the account has to somehow 

decide what access to grant them. Typical ways this can be done include: 

 

●Ask the new user’s manager (in the hope that they know!) 

 

●Give them the same access as someone else in their department or with the same job  

(but we don’t know if that person has the right level of access!) 

 

●Guess or give them access to everything (this happens more than you might think) 

 

None of these scenarios is ideal, and quickly leads to access sprawl, which creates significant 

problems in terms of security and efficiency. Security – because your users may well have 

more access than they need, and you have no real way of knowing, and efficiency – because 

time and effort is expended in trying to work out what access to provide, and also to work out 

what access someone actually has if asked (e.g. by an auditor). 

 

Working without RBAC is fine for small organizations but will rapidly get out of hand and 

lead to a world of administrative pain. 

 

The benefits of RBAC 

 

An RBAC based approach to access provides a lot of benefits, not least that it removes the 

guesswork out of making access decisions.  

 

A well defined RBAC model will specify exactly what level of access each role within the 

organization will have. The IT administrator doesn’t need to know this – they just need to 

know which role the user has, and the rest will follow automatically. 

 

Even better – we can synchronize role information from an authoritative source which 

automates the whole process end to end. If we are using the HR system as the authoritative 

source, we can synchronize a user’s job role from HR and map it to a role. So if we create a 

new user in the HR system with a job role of ‘Financial Controller’, then granting of 

appropriate access to Quickbooks and Salesforce can take place automatically with no 

intervention. 

 

Key Elements of an RBAC model 

 

When considering the RBAC model provided within different IGA platforms, make sure it 

can cater for the following scenarios: 

 

Birthright Access  - this is where a large group of users share common access requirements, 

regardless of their role. For example, in most companies – all members of staff need an email 

account, whatever their job. This type of access assignment is known as a birthright, and is at 

the ‘top’ of the RBAC model. 

 

Multiple Roles – Users often have more than one role. For example, a user might be a sales 

executive role, but also have a temporary project role. The IGA system should be allow users 

to have zero, one or many roles, and should calculate the ‘superset’ of access from all of 

these roles together. 

 

Fine Grained Access – Roles don’t typically only grant access to an application – they often determine what rights someone has within an application, so we need to support 

both coarse grained and fine grained access. So for example, the ‘Financial Controller’ role might

define admin level access to Quickbooks and Read Only access to Salesforce CRM. 

 

Best Practice Guidelines when implementing RBAC 

 

The following best practice guidelines are recommended when configuring the ideiio RBAC model: 

 

1) Maximize use of birthright assignments. Try to build a model with as few as 

possible ‘big buckets’ of users where you can assign as many common birthright 

access as makes sense. For example ‘all East Coast Staff’ or ‘all Contractors’. 

Birthright assignments have the lowest administrative overhead, so it really makes 

sense to keep things simple and use as many as you can. 

 

2) 80:20 rule for Roles. Roles provide an extremely powerful way of automating access 

to applications and resources and ensuring that your users only have access to the 

applications and resources they need. However, it can be tempting to try and model 

every possible combination of access to applications as a role. A rule of thumb is that 

this is normally not productive, and a significant amount of effort can be expended 

defining hundreds of roles for little benefit. Instead, focus on modelling the top 20% 

of roles which will cover 80% of your users and use cases. 

 

3) Use self service to fill the gap. Further to the point above, self service is a great way 

to bridge the gap after you have modelled the top 20% of roles. If you make 

applications available for request on demand, with governance provided by access 

request workflows, you can manage access to remaining applications on a need basis. 

If a user needs an application, they can request it, and the application owner can 

decide whether to grant it. Over time, this approach can provide information about 

application usage which can be used to define new identity roles, whilst significantly 

reducing the amount of time spent defining identity roles up front. 

Comments

0 comments

Please sign in to leave a comment.