Page Comparison

Traditional RBAC

Role-Based Access Control (RBAC) is a framework designed to streamline the process of managing permissions across various applications and IT resources within an organization. This approach aligns with the real-world organizational hierarchy, acknowledging that individuals typically perform tasks and access resources in accordance with their specific job title or function. For instance, a large company may have numerous "Standard Employees" who require identical access to common IT resources. Manually managing permissions for each person within this category can be labor-intensive, error-prone, and susceptible to oversight or mismanagement. It is inefficient and potentially risky from a security perspective to maintain individual access levels for vast numbers of employees. By implementing RBAC, an organization can establish a single "Standard Employee" role, define the expected behavior of this role within the IT environment, and assign all standard employees to this role. Consequently, the process of permissions management is simplified, transitioning from managing numerous individuals to managing a single role.

Conventional RBAC methodologies offer a structure that enables organizations to pose and address questions like, "What actions should individuals with a specific job title or role be permitted to perform with our IT resources?" and "How can we distinguish between people with varying roles and resource requirements?" For instance, a common organization may include both Standard Employees and their respective Managers, who must interact with data pertaining to other members within the organization. Nonetheless, due to their differing responsibilities, the extent and nature of their engagement with this information should vary. RBAC facilitates the definition of these interaction discrepancies by assigning distinct permission levels to the two roles. The Standard Employee role may be granted access to view only "public profiles," while the Manager role could be permitted to not only view public profiles but also access more sensitive information.

The following conceptual illustration demonstrates this distinction. In the image, the access granted to each role determines the extent to which an individual in that role can interact with another person's data. In this example, both the Standard Employee and Manager roles can view public profile information (represented by the green arrow connecting the roles to the public profile information). However, the Manager role is differentiated by having additional access to view absence reports (indicated by the green arrow linking the role to the absence reports), while the Standard Employee is restricted from this capability (signified by the red arrow connecting the role to the absence reports).

In a coding context, the following example demonstrates the distinction:

if (user.role == StandardEmployee)
this.application.show(Employee.PublicProfile)

else if (user.role == Manager)
   this.application.show(Employee.PublicProfile + Employee.AbsenceReport)

This pseudo-code illustrates how the application differentiates the extent of employee information accessible to Standard Employees and Managers. When a user with the Manager role logs into the application, they can view both public profiles and absence reports of employees. In contrast, Standard Employees can only access public profiles.

Utilizing roles significantly reduces the management tasks associated with user access. Consider the complications of maintaining access controls for each individual in the Standard Employee role.

RBAC as Resource-Based Access Control

Traditional RBAC (Role-Based Access Control) offers numerous benefits for managing resources but also poses challenges. One significant challenge arises from the top-down approach to resource management inherent in RBAC. As the name suggests, RBAC starts by focusing on roles: defining a role and deciding its capabilities. However, once established, roles can become rigid and require significant effort to align with evolving organizational policies. If it is later decided that the Manager role is overly broad and should be divided into several smaller roles with overlapping yet distinct access needs, the IT department would need to update the application, potentially causing downtime if the application code needs to be modified to accommodate new roles.

if (user.role == DepartmentManager||user.role == HRManager|| ...)
   this.application.show(employee.AbsenceReports)

With each policy change, the process repeats. The IT team would need to revisit the application, investing considerable resources each time a minor change occurs. Moreover, embedding role checks into code as demonstrated above lacks the transparency necessary for maintaining a useful audit trail. As there is no clear external connection between the Absence Reports resource and the roles with access to it, such assignments cannot be audited. Over time, the specific resources each role can access becomes unclear to everyone. The EmpowerID RBAC model addresses these issues, allowing organizations to implement changes with full visibility and without requiring extensive IT team investments. This model differs fundamentally by managing resources from a bottom-up perspective, utilizing a methodology known as "Resource-Based Access Control."

Resource-Based Access Control reframes the questions to better align with the primary purpose of security policies: protecting resources. It starts by identifying what needs protection, rather than determining who can access it. Although this may seem like a subtle distinction, adopting a resource-driven approach to access control results in a highly flexible and granular framework where explicit controls can be placed on each protected resource. Revisiting the Absence Reports example, Resource-Based Access Control would implement the code as follows:

if (user.isAllowedToViewEmployeeAbsenceReports)
   this.application.show(employee.AbsenceReports)

This pseudo-code does not specify a particular role and is unconcerned with the user's identity. It simply verifies whether the user (regardless of their identity) is authorized to view the report and displays or hides it based on the result of that verification. This approach allows organizations to assign or revoke the ability to view the report for any user at any time without causing disruption or necessitating code block rewrites.

RBAC in EmpowerID

The EmpowerID RBAC model embraces the Resource-Based Access Control approach, emphasizing resources rather than roles. This allows organizations to concentrate on protecting their resources and the actions that can be executed on those resources. In EmpowerID, these "resource actions" are code segments called "EmpowerID Operations." Each EmpowerID Operation is a safeguarded code object enabling users to perform tasks on a resource object, such as adding a user to a group, creating a mailbox, or viewing a report. Users must be delegated these actions before they can interact with a resource. For instance, if you have an Absence Report, that report will have several EmpowerID Operations associated with it to prevent unauthorized access. So, if you have a user named "Joe" and you want him to view the report, you must grant him that ability by assigning a specific Operation for the report. If later it is decided that Joe needs to edit the report as well, you must assign him another Operation permitting him to do so (which can be done during application runtime without disrupting your users).

Moreover, Operation assignments apply to one resource object only, facilitating the easy implementation of resource-specific management strategies. Therefore, if you have two reports—an Absence Report and a Finance Report—granting users the ability to view and edit one will not provide them with any capabilities for the other. You must grant each Operation equally for each report instance unless delegation is done using inheritance or a query-based collection of reports.

In the image below, there are two protected resource objects on the right side—an Absence Report and a Finance Report—and a user named Joe on the left side. Joe has been delegated the "Use" and "Edit" Operations for the Absence Report, allowing him to view and edit the report in EmpowerID (illustrated by the green arrow with the Operations connecting Joe to the Absence Report). However, Joe has not been granted any Operations for the Finance Report, so he cannot access the report in any way (represented by the red arrow connecting Joe to the red barrier in front of the Finance Report). He cannot even see that a Finance Report exists in EmpowerID.

EmpowerID's RBAC resource-specific model allows you not only to control access to individual objects protected by EmpowerID but also to manage access to particular components within an object. For instance, you can use Operations to secure specific sections or fields within sensitive reports. Consequently, you can grant Joe permission to view and edit the Absence Report while restricting his access to certain components of that report. This level of control accommodates even the most fine-grained security policies.

In addition to assigning access to single users like Joe, EmpowerID allows you to assign access to groups, roles, or query-based collections of users. Unlike traditional RBAC, which limits role assignments to static code segments, EmpowerID's resource-based assignments are dynamic. You can modify the details of any assignment for any resource to any user at any time, all during application runtime.

Key Objects of the EmpowerID RBAC Model

In our discussion above, we provided an overview of RBAC in EmpowerID and explained how it differs from the conventional role-based security model. We deliberately omitted some details to keep the discussion focused. Instead of concentrating on roles and their permissions, EmpowerID starts by defining resources and actions that can be performed on them. These actions, called EmpowerID Operations, are written as protected code blocks. Only after defining these Operations does EmpowerID consider the user. Transitioning from resources to users involves more than merely creating a resource Operation and assigning it to a user. Although this is the high-level process of granting a user the ability to interact with a resource, this process involves several other objects essential to the EmpowerID RBAC model. Understanding these objects as defined by EmpowerID is crucial for successfully managing your resources with the platform.

Resources and Resource Types

Resources are the lowest-level secured objects subject to access control, such as individual reports and users. Resources belong to resource systems, which are specific directories or IT systems containing them. Resource systems can include Active Directory domains, LDAP directories, HR systems, Microsoft Exchange Organizations, SharePoint Farms, custom applications, and even the EmpowerID system itself. All objects of any type managed by EmpowerID securely have a resource entry in the EmpowerID Identity Warehouse, uniquely identifying the resource and resource type. Resource types exist for all secured objects, including EmpowerID system applications and components, as well as external system resources protected by EmpowerID.

Each resource object is cataloged by resource type to support different properties associated with those resource types and to allow a consistent interface for managing those objects in EmpowerID. Generally, the nomenclature used for a resource object matches its resource type. Access to these resources in EmpowerID occurs through assigning external system rights and EmpowerID Operations specific to the resource type being accessed via EmpowerID objects known as "Access Levels."

Access Levels

Access Levels are bundles of EmpowerID Operations and/or native external system rights specific to a resource type. When assigned to a user, they grant the ability to perform those operations and rights on the relevant resource. Access Levels are application or resource type-specific definitions (known as "Access Level Definitions") of a set of rights and operations relevant to resources derived from a particular resource system.

Access Levels are essential to delegations in EmpowerID and are the means by which a user receives access to resources. Direct assignment of EmpowerID Operations or native system rights to users is not possible. Instead, those assignments are made to Access Levels and then assigned to users.

In its simplest form, this can be represented in the following way:

Access Levels serve as both a buffer between resources and users and a conduit for users to connect with resources. Operations and/or rights assigned to Access Levels (through their Access Level Definitions) establish boundaries around each resource object, restricting users' actions on the resource.

For example, consider a scenario where there is a Quarterly Absence Report, a group of users, and an Access Level for the report. The Access Level includes a single EmpowerID Operation: the Use operation. This operation is a code action that, when executed against a specific report object, enables the report to be viewed in EmpowerID. Only certain individuals should be able to view the report, as represented by "User Group B." This group can view the Quarterly Absence Report because it has been assigned an Access Level containing the Use operation for the report. However, User Group A lacks an Access Level with the Use operation for the report, so they will not be able to view it.

Access Levels can be customized to grant any type of access to a resource object, provided the object is capable of handling the appropriate rights and operations. For instance, for the Quarterly Absence Report, you could create additional Access Levels and add operations to grant users the ability to edit the report's contents, move the report, delete the report, and more.

Access Level Assignment Scope

When assigning Access Levels to users, it's crucial to consider the scope of that assignment. Scopes allow you to limit the objects affected by an Access Level assignment. By applying a scope to an Access Level assignment, the assignee can only impact resources within the scope's parameters. Scopes work in conjunction with a resource's location and can be of the following types:

1. Direct – A direct assignment provides users with access to a specific Access Level for a particular resource object. The assignee can perform actions defined by the operations and rights of the Access Level for that specific object. For example, if you directly assign an Access Level that grants administrative tasks for an Exchange Mailbox to a user, they can perform those tasks on that mailbox in the EmpowerID user interface and approve the same tasks for unauthorized users.

2. By Location – Location-scoped assignments allow users to affect all resources at or below the location of those resources in your organizational structure. For instance, if you assign an Access Level that grants administrative tasks for Exchange Mailboxes to a user scoped by a location named "Sydney," they can perform those tasks on all mailboxes at or below the Sydney location. The assignee cannot affect any other mailboxes outside the Sydney location.

3. Relative Resources – Relative-scoped assignments restrict the assignee's ability to impact select resources to only those related to the assignee. These resources are evaluated at runtime and can be of the following types:

   a. Objects in the assignee's location and below – This grants the assignee the ability to affect select resources at or below their location.

   b. Objects in the assignee's location and above – This grants the assignee the ability to affect select resources at or above their location.

   c. The person object "Self" – This grants the assignee the ability to affect all resources related to themselves, such as any report objects they are authorized to see based on their role within the organization.

4. Target RBAC Containers – RBAC Containers are collections of resources specific to certain EmpowerID actor types, allowing location-independent delegations. RBAC Containers include:

   a. Target Management Role – This grants the assignee the ability to affect all people belonging to the target role, regardless of those people's location.

   b. Target Group – This grants the assignee the ability to affect all user accounts and people belonging to the target group, regardless of the group members' location.

   c. Target SetGroup – This grants the assignee the ability to affect all resources belonging to the SetGroup, regardless of the resources' location.

The following image illustrates Access Level assignments granted to three different assignees for resources scoped by location. In the first assignment, John Smith has a direct Access Level assignment for one mailbox and cannot access any other mailboxes with that Access Level. In the second assignment, members of the Helpdesk Admins Group have an assignment for all mailboxes in the Offices OU and below. In the third assignment, all people assigned to the Helpdesk in the Sydney Business Role can access mailboxes in the Sydney location only.

Management Roles

Access Levels act as both a buffer and conduit between users and resources. However, directly assigning resources to users through Access Levels is not advised, particularly when managing large numbers of users. While Access Levels offer granular access control over resources and enable EmpowerID to track assignments, using them for corporate-wide delegation management on an individual basis can become impractical and time-consuming. As a result, EmpowerID recommends using another role type, known as "Management Role," for delivering resources to users.

Management Roles are user-defined containers that hold collections of Access Levels packaged together into responsibility or job-based bundles. This allows for efficient and straightforward bulk assignments of resources to users, aligning with their job functions. Management Roles are fully manageable EmpowerID objects that can contain any number of Access Levels for any resource type, granting users the ability to interact with each resource according to the EmpowerID Operations and/or native system rights added to those Access Levels. As containers of Access Levels, Management Roles rely on Access Levels to provide users with functional access to resources. Without Access Levels, Management Roles are merely empty containers, incapable of offering any resource access.

The following image illustrates the relationship between resources, Management Roles, Access Levels, and users in EmpowerID. The Management Role connects users and resources via the Access Levels contained within the role. As the Access Levels are part of the Management Role, their capabilities are passed on to users with the Management Role.

T-RBAC Management Role Model

EmpowerID extensively utilizes Management Roles for its out-of-the-box granular roles, delegating access to specific user interfaces, objects, and actions. These activity-based or task-based roles are divided into three primary types, which segregate the access they grant and allow them to be easily combined and reused without creating and maintaining new roles. The image below uses a Venn diagram to visually represent the three types of T-RBAC Management Roles and how they merge to enable task-based access.

To elaborate, "UI-" Management Roles grant access to user interface elements, such as pages and controls, as well as the ability to run workflows. "VIS-" Management Roles provide visibility access to view specific object types or resources within a particular scope, such as at the organizational level or those in or below an organizational location. "VIS-" Management Roles also regulate access to API endpoints, allowing users or applications to make calls to retrieve data for specific object types. Lastly, "ACT-" Management Roles authorize users 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.

Management Roles and Definitions

In EmpowerID, Management Roles are derived from Management Role Definitions. These definitions enable multiple Management Roles to inherit a shared set of Access Levels without managing those assignments in each child Management Role. This is useful because it allows common access for a set of Management Roles to be defined and managed from one Management Role Definition, while also permitting customization of each child Management Role with additional Access Levels for unique resource access. Users cannot be assigned to Management Role Definitions.

For example, consider a default Management Role Definition and Management Role provided by EmpowerID: the IT Administrator Management Role Definition and its child, the Enterprise IT Administrator Management Role. The IT Administrator Management Role Definition includes 345 Access Levels, granting access to general pages, workflows, and other resources that IT Administrators might need. As a child of the IT Administrator Management Role Definition, the Enterprise IT Administrator Management Role inherits these 345 Access Levels and contains eight additional Access Levels scoped at the "Anywhere" location, providing enterprise-wide capabilities for defined resources. When assigned to a user, that user can run workflows in the Management Role against all objects related to the workflow, regardless of their location within the enterprise.

The following image depicts the relationship between the IT Administrator Management Role Definition and the Enterprise IT Administrator Management Role. As the parent, the Management Role Definition passes all of its Access Levels to the child Management Role, which contains additional Access Levels to define its scope. While this Management Role's scope is enterprise-wide, additional Management Roles can be created from the Management Role Definition with their unique Access Levels and scopes. The primary difference between the Management Role Definition and the Management Role is scope. Management Role Definitions typically lack scoped assignments, while Management Roles contain assignments scoped to various locations, such as the "Anywhere" location.

Although EmpowerID provides default Management Role Definitions with Management Roles scoped at the Enterprise level, many organizations require responsibilities like that of an IT Administrator to be distributed across their enterprise to Management Roles with regional scope. Management Role Definitions can have multiple child Management Roles, allowing for the creation of regional IT Administrator Management Roles for every region within an enterprise, with Access Levels to scope their influence accordingly. This way, each regional IT Administrator Management Role can impact resources in their region only. For instance, if you have organizational locations in "London," "New York," and "Sydney," you could create a London IT Administrator Management Role, a New York IT Administrator Management Role, and a Sydney IT Administrator Management Role from the single IT Administrator Management Role Definition. Then, assign these Management Roles to IT Administrators in London, New York, and Sydney, respectively.

The following image illustrates the relationship between the IT Administrator Management Role Definition and the mentioned child Management Roles. Each child is a separate instance of the parent, with additional Access Levels that scope the child's influence to the intended location only. As a result, assignees of the London IT Administrator Management Role can only affect resources in London; assignees of the New York IT Administrator Management Role can only affect resources in New York; and assignees of the Sydney IT Administrator Management Role can only affect resources in Sydney.

In addition to the general access to resources provided by the Management Role Definition, each child Management Role can be further customized with Access Levels for access to resources unique to that specific Management Role. For instance, the London IT Administrator Management Role could have an Access Level assignment to an EmpowerID workflow or page that is not required by the New York IT Administrator Management Role or the Sydney IT Administrator Management Role. This allows for greater flexibility and customization in managing access and responsibilities for different regional roles within an organization.

EmpowerID Locations

Locations play a vital role in the EmpowerID RBAC model, as they provide a means to organize and assign resources. In EmpowerID, these locations are known as "EmpowerID Locations," which act as containers for grouping resources and scoping access. There are two main types of Location trees in EmpowerID: the "External Locations" tree and the "EmpowerID Locations" tree. The External Locations tree mirrors the actual locations of resources in connected resource systems, while the EmpowerID Locations tree is a user-defined logical representation of an organization's structure that can map to real resource locations in the External Locations tree.

When EmpowerID connects to a resource system, it replicates the structure of that system into the External Locations tree, creating a dynamic link with the actual resource locations. After populating the External Locations tree, you can create EmpowerID Locations, map them to External Locations, and use those EmpowerID Locations to allocate resources from your resource systems to users within your organization.

In the context of our London, New York, and Sydney example, the image below demonstrates how the trees might appear in EmpowerID after connecting, mapping, and inventorying a resource system. Although the naming in the logical tree closely mirrors the naming of locations in the External tree, you can name locations in the logical tree as desired. The green arrows from locations in the External Locations tree to locations in the EmpowerID Locations tree signify the mapping of those locations, enabling you to manage resources in external locations from their corresponding mapped locations in the EmpowerID Locations tree.

EmpowerID Locations consist of Logical Locations, External Locations, All IT Systems, and Resource Systems Locations. Logical Locations are user-defined representations of an organization's structure that map to the physical locations of resource systems. External Locations depict the actual locations of resources in resource systems. All IT Systems is a default EmpowerID location that contains locations for all IT systems protected by EmpowerID, including EmpowerID itself. Resource Systems Locations are unique locations in EmpowerID that represent the structure of various connected resource systems.

Locations in EmpowerID consist of the following categories:

1. Logical Locations
   Logical locations in EmpowerID represent the organizational and geographical structure of an enterprise, mirroring its operational model. These optional, user-defined locations create intuitive and business-friendly nodes on a hierarchical tree, making it easier for delegated users to interact with system resources. Logical locations map to the physical locations of resource systems and always reflect the resources within that location. When mapping occurs, all resources or objects in the directory are assigned to their corresponding logical location for delegation purposes. If a resource is removed from the external location, it is also removed from the corresponding logical location, and vice versa.
   

2. External Locations
   External locations represent the actual locations of resources within resource systems.
   

3. All IT Systems

   The All IT Systems location is a default EmpowerID location containing locations for all IT systems protected by EmpowerID, including the EmpowerID system itself. EmpowerID creates and dynamically maintains locations representing various resource systems, such as Active Directory, Microsoft Exchange, and Microsoft SharePoint, which are connected and managed through the inventory process. Resources inventoried from managed resource systems automatically exist in their corresponding EmpowerID location and update if changed in the external system. The internal structure of these locations should not be reorganized or modified, as they map to actual resources.

   These locations differ from standard EmpowerID locations in a few key ways:

   • Due to their dynamic nature, All IT Systems locations are hidden from role and location selectors for assigning Business Roles and locations to Person objects, except when using the actual structure of Active Directory as a business location.

   • These locations are maintained automatically via inventory, moving when moved in the external system and deleted when deleted in the external system.

   • All IT Systems locations are not mapped to external locations with the RBAC Mapper, as they automatically map one-to-one to an actual external location.

   • Resources are not assigned to these locations, as the resources belonging to these locations reflect what exists in the external location.
     

4. Resource Systems Locations
   Resource Systems Locations are unique locations in EmpowerID representing the structure of various connected resource systems. These locations are contained under the All IT Systems node of the EmpowerID Locations tree.

SetGroups

SetGroups are made up of Sets, which are code–based or LDAP–based queries resulting in collections of people or resources. SetGroups are not locations themselves, but can be mapped to one or more locations so that the resources belonging to the SetGroup belong to any mapped locations.

EmpowerID Actors

In EmpowerID, RBAC actors are the "who" of EmpowerID's RBAC model. Actors are those resources in your environment that can receive Access Level Assignments to perform some type of action against other resources. While RBAC actors can be Person objects, accounts, groups, SetGroups, Management Roles, and Business Roles and Locations (in that each of these resource types can act against other resource types), the actions performed is always accomplished by the Person object that owns the account, is placed in a group or SetGroup, or assigned to a Management Role or Business Role and Location. All assignments are proxies used to assign access to Person objects.

EmpowerID Person

In EmpowerID, a person is an object in the EmpowerID SQL–based Identity Warehouse that links together the user accounts, the permissions assignments, the audit history, and the management policies associated with that person, in whatever directories they may be located. Persons are the true actors in EmpowerID in that all actions performed via the delegations granted by Access Level assignments and Management Role assignments, regardless of which actor type received the delegations, are ultimately performed by an EmpowerID Person. Thus, the EmpowerID Person is the base identity in the EmpowerID RBAC model and is necessary for RBAC assignments to occur, regardless of which actor type is the recipient of the assignment. In other words, assignments of resources to accounts, groups, Management Roles, SetGroups or Business Roles and Locations will only have effect if those objects are linked to EmpowerID Persons. If a user does not have an EmpowerID identity, that user cannot be the recipient of an RBAC assignment. Users without corresponding EmpowerID Person objects will simply not be able to affect resources in EmpowerID. The only exception to this rule are the few workflows configured for anonymous use. The following image shows the primacy of the EmpowerID Person in EmpowerID. The EmpowerID Person brings together all the identities of users in disparate systems into one manageable object that can be used to authenticate those users in those systems without needing to leave EmpowerID.

Groups

A group is a collection of user accounts residing in a directory outside of EmpowerID. In EmpowerID, these user accounts are linked to the EmpowerID Person objects that own them, which makes groups simply collections of accounts that resolve to people. This allows EmpowerID to support using groups to assign permissions across directories and IT systems. In essence, an assignment of rights to a group grants those rights to the Person objects that own the member user accounts. This means that groups can be used as collections of Person objects for assignment and the group is not required to be an object in the same directory (or alternate directory technology). For instance, Active Directory groups can be used to grant permissions in any resource system (such as HR systems and custom applications, etc).

Business Roles and Locations

A Business Role is a user–defined hierarchical container for a grouping of EmpowerID Person objects that can be used for delegating access to resources based on a particular job function; in its simplest form, an EmpowerID Location is container for holding resources. These two objects combine in EmpowerID to determine a collection of people based on their job function and location within an organization, allowing for polyarchical RBAC resource assignments. This is implemented in EmpowerID via tree interfaces (with inheritance) that allow for the intersection of Business Roles with Locations to support the following:

• Static assignments of people – You can directly assign individuals to a Business Role and Location combination based on their job function and location that allows that person to have access to the resources granted to the Business Role and Location. For example, if you have a "Sales Manager" Business Role and for the "London" location that has been assigned all the resources that a Sales Manager in London needs, you can then assign the "Sales Manager–London" Business Role and Location to a specific EmpowerID Person. This will give that person access to all the resources you assigned to the Business Role and Location.

• RBAC mapping – Business Role and Location mappings allow existing physical directory locations and roles to be mapped to logical EmpowerID Locations for an easy resource management strategy that hides the complexity of the back–end directory structure from business users. For example, if you have multiple AD or LDAP directory containers for London, those containers can be visually mapped to single virtual EmpowerID "London" location. Once the mapping occurs, the resources in the physical directory containers "belong" to the corresponding EmpowerID Location. Then when people are assigned to a Business Role and Location, they will receive access to the resources in that location in the manner defined by the Access Level assignments granted to the Business Role and Location.

• SetGroup mapping – SetGroups that contain collections of EmpowerID Person objects can be mapped to Business Roles and Locations to allow the people in that SetGroup to receive the Access Level assignments granted to the Business Role and Location. For example, if you have users in your organization with a Job Title of "Help Desk Technicians" and a City of "New York," you can use a SetGroup to dynamically contain users with those attributes and then map the SetGroup to a corresponding EmpowerID Business Role and Location (such as "Help Desk Technicians" Business Role in the New York location).

Management Roles

As discussed above, Management Roles are bundles of Access Levels packaged together to allow for the quick and easy bulk assignment of resources to people in a way that matches their job function.

SetGroups

A SetGroup is a logical grouping of LDAP or code–based queries, called "Sets," that return collections of people or resources that can be used to dynamically assign resources. SetGroups can be both an EmpowerID Actor type as well as a simple resource type, depending on the objects contained within the SetGroup. Therefore to use SetGroups as an EmpowerID Actor capable of performing tasks against other resources, the SetGroup must return collections of people.

Polyarchical RBAC

For situations in which organizations prefer utilizing Business Roles for managing their resources, or would like to implement a blend of Resource-Based Access Control and Role-Based Access Control, EmpowerID offers a polyarchical RBAC model capable of significantly improving the management of Business Roles compared to conventional models. The term "Polyarchical RBAC" indicates that the resource management model provided by EmpowerID enables resources to be allocated based on a combination of an individual's function within the organization (their Business Role) and their work location (their Location). This intersection of Business Roles and Locations results in a substantially smaller "role footprint" than is achievable with most RBAC approaches, allowing for more precise resource assignment to multiple users sharing the same role.

To illustrate this point, let's examine how both models tackle managing resource access requirements for a Teller, a position commonly found in banking institutions. It is generally acknowledged that most tellers perform similar tasks using comparable resources. Therefore, managing access to these resources through RBAC appears relatively uncomplicated: A "Teller" role is created, all tellers are assigned to that role, and the necessary resources for tellers are allocated to the Teller role. Initially, everything seems satisfactory, with only one role required. However, complications may arise if the banking institution has branches situated in numerous cities, regions, or even countries (e.g., branches in New York, London, and Sydney). Although each teller requires access to a shared pool of resources due to their job, they would also need resources unique to their location. Tellers in New York would require access to New York-specific resources but not those in London or Sydney, and vice versa for tellers in other locations. In this scenario, utilizing the same Teller role for all tellers becomes problematic, as it would generate a "super role" that grants each teller access to resources beyond their purview, posing an excessive security risk and contravening the principle of minimum privilege. So, how does RBAC tackle this issue?

A majority of conventional RBAC implementations would resolve this challenge by establishing distinct roles for each teller location. Consequently, tellers in London, New York, and Sydney would possess their own roles, as demonstrated in the accompanying image.

Although creating separate roles for each teller location might seem sufficient, this approach can rapidly become unmanageable, resulting in role bloat and eventual confusion regarding which roles possess access to specific resources. Imagine tellers employed by the same banking institution with branches in every major city across the globe.

As previously mentioned, EmpowerID's polyarchical model enables a significant reduction in an organization's role footprint by permitting resources to be assigned to users based on a combination of their Business Roles and Locations. This method allows for the mitigation of the aforementioned role bloat using only one Teller Business Role without generating a "super role." This is achievable because EmpowerID facilitates differentiation in the resources allocated to a Business Role according to the location of said resources. Consequently, tellers in London, New York, and Sydney can all possess the same Business Role without gaining access to each other's resources. EmpowerID would thus address the role situation as follows:

The decision to utilize Business Roles and Locations when delegating resources is contingent upon the degree of immediate visibility desired for overseeing the assignment of those resources. Since these assignments transpire through the intersection of two distinct EmpowerID objects, the EmpowerID Business Role and the EmpowerID Location, auditing the access each individual has to resources necessitates a few additional details compared to using the Management Roles elaborated upon earlier. Regardless of the chosen approach, RBAC in EmpowerID proves to be a potent concept, fully capable of satisfying the requirements of even the most intricate security policies.