Business Roles typically represent job positions within an organization and are used to bundle and report appropriate Compliant Access. However, modern organizations are composed of cross-functional teams working on initiatives or projects, and not all access is either job-based or necessarily assigned directly to each Business Role. In EmpowerID, this type of access is commonly bundled into manageable Task-Based RBAC or T-RBAC “activity-based” functional roles known as “Management Roles.” These Management Roles can be designed to grant the bundles of technical roles, entitlements, and permissions in external systems required to complete everyday job duties or tasks, such as “New Customer Onboarding.” It is quite possible that, in an organization, multiple Business Roles might perform this task, and, therefore, granting the task as a bundle makes access far more manageable and auditable. Moreover, it is this middle layer that bridges the gap between the organization’s job-based business roles and their cryptic, external system technical entitlements and permissions and enables the user to perform their business activities. As shown in Figure 1 below, these IAM activity-based roles then act as an ‘Anti-Corruption Layer’ (to borrow a Microservices term) by ensuring that the business activities performed by various job roles remain unaffected by any changes to the IT landscape, in turn protecting the business processes and operating model.
Figure 1: IAM Acting as an Anti-Corruption Layer Insulating the Business Model from Technical Changes and Limitations
To further expand upon this concept, if the organization were to define the activities performed by its sales staff and directly map the required technical roles and permissions to these business roles, any change in the system used to perform these activities would require a redesign of multiple Business Roles. Now though, with Management Roles acting as our anti-corruption layer, the Business Roles would remain the same even if sales tasks were now spread across numerous SaaS applications. In this instance, the only changes required would be mapping the clearly defined activity-based Management Roles to the new system’s corresponding technical roles and permissions. One further added advantage is that the technical system owners could handle this mapping without requiring the business team's business role redesign and involvement.
In addition to providing activity-based roles, Management Roles are also used for teams, cross-department collaborations, or project teams. This tier is looser and more flexible than the Business Role tier as it is less tied to a person’s job description.
T-RBAC is used internally by EmpowerID to organize who may use which user interfaces, APIs, and workflows, who may see which objects and data, and who may perform which actions against objects. T-RBAC separates access for UI, data visibility, and data access to avoid bundling and over-permissioning. As shown in Figure 2, these are broken down into three primary types to segregate the access they grant: “UI/API” roles, Data Visibility (“VIS-”) roles, and Data Access roles (“ACT-“).
Figure 2: Venn diagram of the 3 types of T-RBAC Management Roles and how they combine to enable task-based access
As seen above, users must have a combination of these Management Roles to have task access. When assigning Management Roles, keep the following in mind:
UI/API‑Management Roles grant access to user interface elements, such as pages and controls, and access to run workflows.
VIS‑Management Roles grant the visibility access to view specific types of objects or resources in a particular scope, such as at the organizational level or those in or below an organizational location. VIS‑Management Roles also control access to the API endpoints that allow users or applications to make the calls to retrieve the data for that object type.
ACT‑Management Roles grant the authorization to perform specific actions or “operations” within EmpowerID user interfaces and workflows against scoped data, such as individual mailboxes or all objects of a particular type by organizational location. Segregating these activity-based or task-based roles in this manner allows them to be easily reused and “composable” into any number of combinations without requiring the creation and maintenance of new roles.