Problem solve Get help with specific problems with your technologies, process and projects.

Role-based access control: Making an enterprise RBAC implementation easier

Learn the benefits of role-based access control based on job functions of network accessing employees, and how to make an RBAC implementation easier.

I'm trying to advocate for our organization to use a more traditional role-based access control (RBAC) model. As...

it stands now, most users have overly broad systems access, but the prospect of having to assess and define user roles with virtually every department manager in the company is so daunting that even our CISO doesn't want to do it. Is there a way to make the process of creating user access roles less painful, or is there an easier approach?

Role-based access control (RBAC) has been a recognized way of managing access for about a decade.  It has an advantage over traditional application access controls (ACLs), as RBAC defines user access based on the business need for retrieving data instead of using the ACL-based connectivity built into the technical data controls – read, write, delete.  However, designing RBAC isn’t as straightforward as ACL designs.  RBAC logic and access determinations are dependent on an organization’s business structure, culture and management style.  These determinations can then be further broken down into a company’s organizational and functional roles. For example, a user may be an organizational supervisor as well as a functional lead engineer. Finally, if an organization is struggling with RBAC, this may be a clear indication of a large number of “knowledge workers,” or people who don’t have defined tasks that they perform during a workday, which can exacerbate the problem of grouping users together for access. 

So how does one approach an RBAC implementation within an enterprise? The best place to start is to inventory the types of business categories that define the members of an organization and the best place to get this information is from an organization’s HR department.  HR departments have categorized records of worker roles, such as executive, manager, dock worker, engineer, teller, writer or agent.  These categorizations can help the RBAC designer to understand how the organization is defined from a “functional” business perspective. 

Using workers' functional roles with clearly defined tasks is the best way for an organization to start its journey into role-based access management.  Since the focus of many RBAC projects is on high-value data handled by high-ranking personnel, this is a risky and difficult task.  The RBAC designer should start with an easy problem in order to gain the experience needed to understand all the variables that go into defining an RBAC role.  Starting with clearly defined functional roles will show immediate results with little work and start the slow progression from ACL-based access to RBAC.  For example, bank tellers, sales executives, warehouse workers, manufacturing floor workers and others all need access to electronic data, but have well-defined, fixed tasks that they perform.  Defining the systems they access, the locations and time of day they work, and the changes they’re authorized to make are easy to define from an RBAC perspective.

Once the functional business personnel have been defined, the RBAC designer must begin to understand the knowledge worker, executive, and other more flexible roles; those people whose job functions change on a daily, even hourly basis.  Unfortunately for the designer, many companies pigeonhole knowledge workers in functional roles for payroll and reporting practices, although they operate in a much looser business model.  For example, HR may have a Manager Grade II classification, but may assign this designation to lead engineers, architects, QA team managers, IT administrators and physical plant leads, all of whom perform a myriad of diverse tasks during the day.  For this class of workers, the designer should look at designing the role-based security model primarily based on organizational role, as the functional role will not be granular enough to provide the right level of access requirements needed.  Again, the goal should be to start with those people who have less flexibility in the tasks they perform.  As the populations within an organization are defined over time, the RBAC designers will have the opportunity to pick up the skills and experience to continue on with the more challenging roles. 

The process of ensuring a successful RBAC implementation is a difficult road to travel and within loosely organized companies it can be more of an art than a science. If after reading this response an organization decides it’s too challenging to tackle RBAC, my advice would be to seek professional assistance from a reputable service organization that specializes in RBAC role modeling.  While it’s an additional cost to the organization, in the long run it is less costly than addressing this problem through trial and error.

Ask a question

Randall Gamby,'s resident expert on identity management and access control, is standing by to answer your toughest enterprise IAM questions. Send in your questions today! (All questions are anonymous.)

This was last published in January 2012

Dig Deeper on Active Directory security