RBAC is one of non-discretionary access control models responsible for execution of business processes in context of employee access within an enterprise.
Many large companies decide to implement Role-based Access Control model. Mostly, this is a result of technological changes management initiates to improve internal processes behind IT systems. Very often non-efficient technical processes, which hardly follow the business changes, are a direct cause of the decision to initiate RBAC implementation project.
When company starts long-term project aiming to implement new access control model there is a dedicated team focusing on RBAC architecture, design and implementation. This team and the project become independent from other teams and aim to improve corporate internal ecosystem.
Here we would like to show basic technicalities behind RBAC and explain why initiation of global independent project may fail if it does not fully integrate with existing legacy business processes and is not coordinated across several teams.
Roles can be categorized in several ways, depends on business size and IT systems complexity. The model that suits most of the Large Enterprises (LE) defines two main role categories: Business (Organizational) Roles and Technical Roles (Groups). There is a space for different variations using nested roles of the same category. However the simplified model defines two main categories (see Figure 1).
Core Business Roles assignment should be initiated directly or indirectly by HR department. This assignment should be dynamic so any business change has always impact on roles.
There are several techniques to integrate HR processes with Identity and Access Management (IAM) processes. HR system can have dedicated components responsible for access management enforcement, although most often we deal with heterogeneous implementations, where HR system is independent from IAM system. In this scenario, we assign Business Roles in IAM system to an employee through exposed properties (attributes) from HR system.
Next step is to assign Technical roles to corresponding Business Roles. Let’s assume we can leverage existing directory system, where groups are already permissioned over corporate resources. These legacy directory groups act as low level Technical Roles, however when it comes to large IAM infrastructures they actually align better with systems than business processes. Resources are permissioned via these groups by a resource owner like in discretionary access control model.
To better manage these specialized directory groups we can create additional Technical Roles layer in our IAM system, however we focus here on the most simplified scenario. The existing Technical Roles despite whether these are resource groups, application groups, network groups, system groups, policy groups, project groups or others are used by technical teams to permission employees. The common process of giving access rights to a newly hired person or an employee moved within an organization requires entitlements pattern. Support teams most often know these patterns or there is an existing process where either team manager delivers technical roles (groups) baseline or simply other employee entitlements are used as a rights provisioning baseline. This is the point where we turn our RBAC rollout model upside down. We should leverage these existing processes and deliver tools and education to these technical teams so they act as access management team responsible for building our roles. Every time new employee’s identity is provisioned into corporate systems, the team using IAM system instead of duplicating rights from other employee can save the rights baseline as a “profile”. This “profile” is our future candidate for Business Role. Next time employee joins the same team instead of rebuilding entitlements from scratch the “profile”, our Business Role can be applied.
Many leading market companies decided to initiate RBAC project. Unfortunately, large amount of these companies either failed or still try to rollout the RBAC system. The main issue is that the roles model created, when reach maturity from business perspective, it is already behind the technical changes. Also when roles are tailored to suit the technical provisioning and access control processes, the business is already changed and the whole implementation phase should move back to design phase to align the design with business. In an enterprise, where number of applications and resources exceeds dozens of thousands, the team dedicated to identify granular access rights, assign it to Technical Roles and next assign these roles to right Business Roles cannot address all the changes as are actually not a part of a unit that coordinates or implements these changes.
Experience shows that RBAC implementation should be an on-going process coordinated across several teams and departments aiming to influence already existing processes related to access control. These teams should be provided relevant tools and competent advice aiming to improve existing state rather than change it too quickly. Tier 1 and Tier 2 level teams are the best candidates for the enterprise RBAC enablement initiation. They deal with access control requests on daily basis. They also adjust technical accounts after provisioning and revocation. The same teams probably already worked out the baselines for access entitlements across several teams, departments, resorts, countries, etc. If it is not a part of a corporate knowledge base yet then it should become by giving these teams tools and simple RBAC how-to to facilitate their daily tasks. This is the big step to build the Technical Roles and organize them based on various categories.
“Any design that’s not based on empirical data it’s a design that’s destined to fail!”
Kayne McGladrey – Centrify Corporation