Page Comparison

Traditional RBAC

Role-Based Access Control (RBAC) is a framework designed to allow organizations to more efficiently manage streamline the process of managing permissions across various applications and other protected IT resources . As such, the RBAC model attempts to mirror within an organization. This approach aligns with the real-world organizational structure by recognizing that most individuals within organizations perform tasks against resources related to the function or job title they hold within that organization, accessing resources in a behavior-specific way and that more than one can have the same role. For example, an organization could have hundreds or even thousands of employees classified as "Standard Employees," with each needing to access the same common IT resources in the same way. As can be imagined, 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 falling into within this role can quickly become a time–consuming task prone to error, oversight, and mismanagement. Simply put, maintaining the appropriate level of access to resources for each individual when dealing with large numbers of people is impractical, unwieldy, and from a security standpoint, dangerous. By using 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 create establish a single role, "Standard Employee" role, " define how that role is to "behave" in an IT environment and then place all standard employees into that Standard Employee role. In this way, permissions management is reduced from "the many to the one."

Image Removed

Traditional approaches to RBAC provide a framework that allows organizations to ask and answer, "What do we want to allow people with this job title or role to be able to do 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.

Image Added

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 do we differentiate this for can we distinguish between people with differing varying roles and resource needsrequirements?" For example, most organizations have the instance, a common organization may include both Standard Employees mentioned above and the Managers of those Standard Employees might both need to interact with information about other people within their organization. However, in lieu of the responsibilities associated with what they do in that organization, the amount of interaction they have with that information should differ qualitatively. The use of RBAC allows the differences in that interaction to be defined through the assignment of varying levels of permissions for 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 could have permissions assigned to it that allow those in the role to view may be granted access to view only "public profiles," only, while a the Manager role could have permissions assigned to it that allow those in the role to view be permitted to not only view public profiles , but other also access more sensitive information as well.

The below image shows what this might look like conceptuallyfollowing conceptual illustration demonstrates this distinction. In the image, the access assigned granted to each role determines what a person the extent to which an individual in that role can do interact with another person's informationdata. For our In this example, people in both the Standard Employee role and the Manager role roles can both view public profile information (indicated represented by the green arrow flowing from connecting the roles to the public profile information). However, the Manager role is differentiated in that it has by having additional access granted to it so that someone in that role has the ability to see to view absence reports (indicated by the green arrow flowing from linking the role to the absence reports), while a the Standard Employee is denied that ability (indicated restricted from this capability (signified by the red arrow flowing from connecting the role to the absence reports).

Image Modified

From In a coding perspectivecontext, this could look like 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)

From this This pseudo-code , we can see that illustrates how the application determines differentiates the amount extent of employee information available accessible to Standard Employees and Managers differs. If When a user assigned to with the Manager role logs in to into the application, that user is granted the ability to view the public profiles of employees as well as the absence reports for those same employees. Standard Employees on the other hand, can only view public profiles.As can be seen, the use of roles provides a great tool for minimizing the management tasks involved with user access. Simply imagine the headaches involved with 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

As advantageous as traditional Traditional RBAC (Role-Based Access Control) can be offers numerous benefits for managing resources , it is not without but also poses challenges. One of the biggest of these occurs significant challenge arises from the top-down approach to resource management inherent with Role-Based Access Controlin RBAC. As the name implies, Role-Based Access Control begins with a focus suggests, RBAC starts by focusing on roles: Let's define defining a role and then decide what the role can do. But once the role is defined, it often becomes inflexible, requiring much effort to keep it in sync 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 mentioned above is too encompassing and needs to be broken down into a number of overly broad and should be divided into several smaller roles with overlapping and yet unique distinct access needs, the IT department would need to revisit update the application, making changes that could result in downtime, such as would occur if application code needed to be changed to incorporate the 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)

And with With each new similar policy change to policy, the process would repeat itselfrepeats. The IT team would need to revisit the application, investing significant considerable resources each time the smallest a minor change occurs. But beyond thisMoreover, writing embedding role checks into code as the demonstrated above does lacks the transparency necessary for maintaining a useful audit trail. As there is no clear external link connection between the Absence Reports resource and the roles with access to it, such assignments like this cannot be audited. Over the passage of time, exactly what the specific resources each role can access becomes lost unclear to everyone. The EmpowerID RBAC model was designed with addresses these issues in mind to allow , allowing organizations to implement just such changes with full visibility and without requiring heavy investments by an extensive IT team investments. This model is fundamentally different in that it approaches the management of resources from the bottom–up using the methodologies of a way differs fundamentally by managing resources from a bottom-up perspective, utilizing a methodology known as "Resource-Based Access Control."

Resource–Based Resource-Based Access Control changes reframes the questions being asked to reflect more accurately what it is that security policies are designed to do: protect resources. Thus, Resource–Based Access Control begins with asking what needs to be protected, not who can have access to it. While this may sound semantic, approaching access control from a resource–driven perspective yields 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 by which where explicit controls can be placed on every each protected resource being protected. Returning to our . Revisiting the Absence Reports example, Resource–Based Resource-Based Access Control would write implement the code as follows:

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

As can be seen, this pseudo–code This pseudo-code does not define specify a particular role and does not concern itself with a is unconcerned with the user's identity. It simply checks to see if verifies whether the user (whatever userregardless of their identity) is authorized to view the report , showing or not showing and displays or hides it based on the results result of that checkverification. This approach allows organizations to assign and remove or revoke the ability to view the report to or from for any user at any time without causing disruption or the need to rewrite the necessitating code block rewrites.

RBAC in EmpowerID

The EmpowerID RBAC model is one that reflects embraces the Resource-Based Access Control paradigm; the platform is resource-centric, not role-centricapproach, emphasizing resources rather than roles. This allows organizations to focus concentrate on what they are protecting – their resources and the actions that can be performed against executed on those resources. In EmpowerID, these "resource actions" are blocks of code known as segments called "EmpowerID Operations." Each EmpowerID Operation is a protected safeguarded code object that provides enabling users with the ability to perform tasks on a task against a resource object, such as adding a user to a group, creating a mailbox, or viewing a report. Each of these actions Users must be delegated to users these actions before they can do anything interact with a resource. For exampleinstance, if you have an Absence Report, that report will have a number of several EmpowerID Operations associated with it to protect each facet of that report from unauthorized activityprevent unauthorized access. So, if you have a user named "Joe" and you want Joe to be able to see him to view the report, you must grant Joe him that ability by assigning him a specific Operation for the report that allows him to do so. If later it is later decided that Joe needs to be able to edit the report as well, then you must assign him another Operation that allows permitting him to perform that task. (You can do this at application runtime, causing no disruption to your users.)In addition, Operation assignments are specific do so (which can be done during application runtime without disrupting your users).

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

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

Image Modified

Not only does the EmpowerID's RBAC resource-specific model of EmpowerID's RBAC allow you allows you not only to control access to each individual object objects protected by EmpowerID , it allows you to control but also to manage access to the individual particular components of within an object as well. In the case of the reports mentioned above. For instance, you can use Operations to secure specific sections or even fields on those reports considered more sensitive. Thuswithin sensitive reports. Consequently, you could can grant Joe the ability permission to view and edit the Absence Report , while at the same time denying him the ability to do so with any component on that report. You can therefore control access to meet the demands of the finest–grained 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 these reports to a single user users like Joe, EmpowerID also allows you to assign access to groups, roles, or query-based collections of people. And, unlike the users. Unlike traditional RBAC approach, which limits role assignments to static chunks of code segments, EmpowerID's resource-based assignments are dynamic. You can change modify the details of any assignment for any resource to any user at any time, all at during application runtime.

Key Objects of the EmpowerID RBAC Model

In our discussion above, we provided an overview of RBAC in EmpowerID , showing and explained how it deviates differs from the traditional conventional role-based security model. In doing so, we purposely avoided some details for the sake of the discussion. We wanted you to simply see that rather than focusing on roles and what those roles can or cannot do in an environment, EmpowerID begins with defining resources and the 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 against those resources. We saw that those actions on them. These actions, called EmpowerID Operations, are written as protected blocks of code, called EmpowerID Operations, and that only code blocks. Only after defining those these Operations does EmpowerID concern itself with consider the whouser. Moving Transitioning from the what resources to the who users involves more than simply merely creating a resource Operation and then assigning that Operation it to a user. While at a high level this is what occurs when a user is granted Although this is the high-level process of granting a user the ability to act against interact with a resource, granting that ability involves the use of this process involves several other objects key essential to the EmpowerID RBAC model. Understanding those these objects as defined by EmpowerID is essential to successfully using crucial for successfully managing your resources with the platform to manage your resources. The following provides definitions for these objects, as well as further definitions for the objects discussed above, showing how each object fits together to provide rich resource security.

Resources and Resource Types

Resources are the lowest level secured objects for which access control occurs, such as the individual reports and users discussed above.

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 the specific directories or IT systems in which they are containedcontaining 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 that are managed by EmpowerID in a secure fashion securely have a resource entry in the the EmpowerID Identity Warehouse that , uniquely identifies identifying the resource and the resource type from which the resource is derived. Resource types exist for all secured objects, including the EmpowerID system applications and components of the EmpowerID system itself, as well as those resources belonging to an external system resources protected by EmpowerID.

Each resource object is cataloged by resource type to provide support for the different properties associated with those resource types and to allow for a consistent interface to manage for managing those objects in EmpowerID. Generally speaking, the nomenclature used for a resource object matches that of its resource type. Thus, Exchange Mailbox objects belong to the Exchange Mailbox resource type, SharePoint Web Sites belong to the SharePoint Webs resource type and so on. Whenever a user is granted access to one of these Identity Warehouse objects and makes changes to it, EmpowerID passes those changes to each respective resource system. Access to these resources occurs in EmpowerID occurs through the assignment of assigning external system rights and EmpowerID Operations specific to the resource type of resource 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 type of resource, packaged together as an assignable object that when resource type. When assigned to a user grants that user , they grant the ability to perform those operations and rights against on the relevant resource for which the Access Level pertains. They . Access Levels are application or resource type-specific definitions (known as "Access Level Definitions") of a set of rights and operations that make sense for relevant to resources derived from a particular resource system, such as Exchange Mailboxes, User Accounts, AD Security Groups, and SharePoint sites. Each of these resource types would have its own set of Access Levels defined with different combinations of rights (if applicable) and/or EmpowerID Operations that would apply to each object in that resource system.

For example, an Access Level for the Exchange Mailbox resource type defined with an EmpowerID Operation that allows mailboxes to be deleted will grant any user the ability to delete any mailbox for which the user is assigned the Access Level. This assignment can be as broad as to include all mailboxes within an organization or as limited as to include only a single mailbox. And while the scope of the Access Level can change, the operations and rights of the Access Level per Access Level assignment will not as these are defined and managed at the definition of the Access Level for the resource.

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

Image Removed

Access Levels both place a buffer between resources and users as well as provide the conduit for users to connect with resources. The operations and/or rights assigned to Access Levels (via their Access Level Definitions) place boundaries around each resource object, limiting what those users can do with the resource.

As an example, consider the image below. In the image, there is a Quarterly Absence Report, a group of users, as well as an Access Level for the report. The Access Level is comprised of a single EmpowerID Operation: the Use operation. The Use operation is a code action that can be executed against a specific report object allowing that report to be viewed in EmpowerID. (This is represented by the green arrow flowing from the Use operation to the Quarterly Absence Report.) Given the nature of the report, we want only certain individuals to be able to view it. In our image, those individuals are represented by "User Group B." This group can view the Quarterly Absence Report because it has been assigned an Access Level that contains the Use operation for the report (indicated by the green arrow flowing from the Access Level to the actor). However, User Group A does not have an Access Level with the Use operation for the report (indicated by the red arrow flowing from the Access Level to the actor) and therefore will not be able to see it.

Image Removed

Access Levels can be tailored to grant any type of access to a resource object for which the object is capable through the addition of the appropriate rights and operations. Thus, for the Quarterly Absence Report, you could create additional Access Levels, adding operations to those Access Levels to give users the ability to edit the contents of the report, move the report, delete the report, and so on.

.

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:

Image Added

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.

Image Added

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 is important 's crucial to consider the scope of that assignment. The use of scopes enables Scopes allow you to place limits on limit the objects impacted affected by an Access Level assignment. When you apply By applying a scope to an Access Level assignment, the assignee of that Access Level can only affect the impact resources that fall within the scope's parameters of the scope. Scopes are used work in conjunction with the location of a resource's location and can be of the following types:

1. Direct – A direct assignment

1. provides users with access to a specific Access Level for a

1. particular resource object.

1. The assignee can perform actions defined by the operations and rights of the Access Level for that specific object.

1. For example, if you

1. directly assign an Access Level that grants administrative tasks

1. for an Exchange Mailbox

1. to a user,

1. they can perform those tasks

1. on that mailbox in the EmpowerID user interface

1. and approve the same tasks for unauthorized users

1. .

2. By Location –

1. Location-scoped assignments allow users to affect all resources

1. at or below the location of those resources in your organizational structure.

1. For instance, if you

1. assign an Access Level that grants administrative tasks

1. for Exchange Mailboxes

1. to a user scoped by a location named "Sydney,"

1. they can perform those tasks

1. on all mailboxes

1. at or below the Sydney location. The assignee

1. cannot affect any other mailboxes outside the Sydney location.

2. Relative Resources –

1. Relative-scoped assignments restrict the assignee's ability to impact select resources to only those

1. related to the assignee. These

1. resources are

1. evaluated at runtime

1. and can be of the following types:

   a. Objects in the assignee's location and below – This

1. grants the assignee the ability to affect select resources

1. at or below

1. their location.

   b. Objects in the assignee's location and above – This

1. grants the assignee the ability to affect select resources

1. at or above

1. their location.

   c. The person object "Self" – This

1. grants the assignee the ability to affect all resources related to

1. themselves, such as any report objects they are authorized to see

1. based on their role within the organization.

2. Target RBAC Containers – RBAC Containers are collections of resources specific to certain EmpowerID actor types

1. , allowing location-independent delegations. RBAC Containers include

1. :

   a. Target Management Role – This

1. grants the assignee the ability to affect all people belonging to the target role, regardless

1. of those people's location.

   b. Target Group – This

1. grants the assignee the ability to affect all

1. user accounts and people belonging to the target group, regardless of the

1. group members' location.

   c. Target SetGroup – This

1. grants the assignee the ability to affect all resources belonging to the SetGroup, regardless of the resources' location

1. .

The following image shows 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 . He and cannot access any other mailbox mailboxes with the 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 Help desk Helpdesk in the Sydney Business Role can access each mailbox mailboxes in the Sydney location only.

Management Roles

Although Access Levels serve act as the both a buffer and conduit between users and resources. However, using them to directly assign assigning resources to users , especially when dealing with through Access Levels is not advised, particularly when managing large numbers of users, is not recommended. Aside from the benefits of the granular access controls Access Levels place on resources and the ability of . While Access Levels offer granular access control over resources and enable EmpowerID to track their assignments, using them to corporately manage delegations on a user–by–user for corporate-wide delegation management on an individual basis can quickly become unpractical impractical and time–consuming. For this reasontime-consuming. As a result, EmpowerID recommends assigning Access Levels to using another role type of role, known as the "Management Role," for delivering resources to users.

Management Roles are user–defined containers holding user-defined containers that hold collections of Access Levels that have been packaged together into responsibility or job–based bundles to allow for the quick and easy job-based bundles. This allows for efficient and straightforward bulk assignments of resources to resource users in a way that matches users, aligning with their job functionfunctions. They Management Roles are fully manageable EmpowerID objects that can be filled with contain any number of Access Levels for any resource type and assigned to users to allow them to act upon each resource in a way commensurate with , granting users the ability to interact with each resource according to the EmpowerID Operations and/or native system rights added to each of those Access Levels. As containers of Access Levels, Management Roles depend rely on Access Levels to provide users with functional access to resources. Without Access Levels, Management Roles are nothing more than merely empty containers, incapable of providing offering any resource access to resources.

The following image demonstrates illustrates the relationship between resources, Management Roles, Access Levels, and users in EmpowerID. As can be seen, the The Management Role provides the link between connects users and resources via the Access Levels contained within the Management Rolerole. Because As the Access Levels are part of the Management Role, the abilities of those Access Levels their capabilities are passed on to the users with the Management Role.

T-RBAC Management Role Model

EmpowerID leverages extensively utilizes Management Roles extensively for the its out-of-the-box granular roles shipped to delegate who may see which , delegating access to specific user interfaces, objects, and perform which actions. These activity-based or task-based roles are broken down divided into three primary types to , which segregate the access they grant , allowing and allow them to be easily reused and “composed” into any number of combinations without requiring the creation and maintenance of combined and reused without creating and maintaining new roles. The image below image uses a Venn diagram to visually depict represent the three types of T-RBAC Management Roles and how they combine merge to enable task-based access.

To further elaborate, “UI"UI-“ " Management Roles grant access to the user interfaces interface elements, such as pages and controls along with access , as well as the ability to run workflows. “VIS–“ "VIS-" Management Roles grant the provide visibility access to view specific object types of objects or resources in within a particular scope, such as at the organizational level or those in or below an organizational location. “VIS"VIS-” " Management Roles also control regulate access to the API endpoints that allow a user or application , allowing users or applications to make the calls to retrieve the data for that particular specific object typetypes. And lastlyLastly, “ACT"ACT-“ " Management Roles are what actually grant the authorization authorize users to perform specific actions or “operations” "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 children of derived from Management Role Definitions. These Management Role Definitions allow definitions enable multiple Management Roles to inherit a common shared set of Access Levels without the need to manage managing those assignments in each of the child Management RolesRole. This is helpful as useful because it allows common access for a set of Management Roles to be defined and managed from one Management Role Definition, while also allowing permitting customization of each child Management Role to be customized with additional Access Levels for access to resources unique to that Management Role. Management Role Definitions differ from Management Roles in that users unique resource access. Users cannot be assigned to Management Role Definitions.

As an example of the relationship between the two, let's For example, consider a default Management Role Definition and Management Role that EmpowerID provides out–of–the–box, provided by EmpowerID: the IT Administrator Management Role Definition and its child, the Enterprise IT Administrator Management Role. The IT Administrator Management Role Definition consists of includes 345 Access Levels that delegate , granting access to the general pages, workflows, and other resources that IT Administrators might need, such as the Initiator Access Level for the DeleteMailbox request workflow. (This Access Level allows users to run the DeleteMailbox workflow, which is used to delete mailboxes and the AD user account associated with the mailbox. ) As a child of the IT Administrator Management Role Definition, the Enterprise IT Administrator Management Role inherits each of those these 345 Access Levels , including the Initiator Access Level for the DeleteMailbox workflow, as well as and contains eight additional Access Levels scoped at the "Anywhere" location, giving the Management Role enterprise–wide capabilities against the resources for which it is defined. Once the Management Role is providing enterprise-wide capabilities for defined resources. When assigned to a user, that user will be able to can run the workflows in the Management Role against all objects related to the workflow, regardless of their location within the enterprise. For example, two of the Access Levels scoped at the Anywhere location are the EmpowerID Administrator Access Level for the User Account resource type and the EmpowerID Administrator Access Level for the Exchange Mailbox resource type. These Access Levels allow all EmpowerID Operations that can be performed against both user accounts and mailboxes in EmpowerID to be accomplished by anyone with the Access Level. Thus, an assignee of this Management Role will have the ability to run the DeleteMailbox workflow against any mailbox and user account anywhere within EmpowerID.The following image shows 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 give it scope. While the scope of this particular Management Role is 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 own unique Access Levels and scopes. Note that the The primary difference between the Management Role Definition and the Management Role is scope. Management Role Definitions typically are set up without lack scoped assignments, while Management Roles contain assignments scoped to any number of various locations, such as the "Anywhere" location.

Although EmpowerID provides default Management Role Definitions with Management Roles scope scoped at the Enterprise level, most organizations will have policies requiring many organizations require responsibilities like that of an IT Administrator to be distributed across their enterprise to Management Roles with regional scope. Because Management Role Definitions can have as many multiple child Management Roles as needed, a , allowing for the creation of regional IT Administrator Management Role can be created Roles for every region within an enterprise, with Access Levels to scope the their influence of those Management Roles accordingly. In this This way, each of the regional IT Administrator Management Roles Role can affect impact resources in their region only. So for exampleFor 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 one single IT Administrator Management Role Definition and then assign those . Then, assign these Management Roles to IT Administrators in London, New York, and Sydney, respectively.

The following image shows illustrates the relationship between the IT Administrator Management Role Definition and the above mentioned child Management Roles. Each child is a separate instance of the parent, with additional Access Levels that scope the child's influence of the child to the intended location only. ThusAs 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.

Beyond 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 exampleinstance, the London IT Administrator Management Role can could have a an Access Level assignment to an EmpowerID workflow or page that is not needed required by the New York IT Administrator Management Role or the Sydney IT Administrator Management Role.

EmpowerID Locations

Locations play an important part in the EmpowerID RBAC model: In order to assign resources to users, those resources must be located somewhere. In EmpowerID, the "somewhere" is an object known as the "EmpowerID Location." An EmpowerID Location is a container used to group resources for scoping access to those resources. This occurs through the use of two types of Location trees: The "External Locations" tree and the "EmpowerID Locations" tree. The External Locations tree is a representation of the location of resources in the actual resource systems to which EmpowerID is connected. EmpowerID maintains a dynamic link with these resource system locations, reflecting any changes that occur in the structure of an actual external location in this tree. The EmpowerID Locations tree is a user-defined logical representation of the organizational and geographical structure of an enterprise that can be mapped to actual resource locations in the External Locations tree.

When EmpowerID connects to a resource system, it copies the structure of that resource system into the External Locations tree, maintaining a dynamic link through it to the actual locations of the resources in the resource system. Once the External Locations tree is populated, you can create EmpowerID Locations, map them to the External Locations and then use those EmpowerID Locations for assigning the resources in your resource systems to the users in your organization.

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.

Keeping with In the context of our London, New York, and Sydney themeexample, the below image shows an example of what these trees could look like in EmpowerID once a resource system has been connected, mapped, and inventoried. In this particular instance, the naming applied to 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 tree. However, you can name the locations in the logical tree as desired. The green arrows pointing from the locations in the External Locations tree to locations in the EmpowerID Locations tree indicate a mapping of those locations. This means that you can manage the resources in those external locations from their mapped counterparts in the EmpowerID Locations tree.

Image Removed

Locations in EmpowerID comprise the followingLocations 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.

Image Added

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

1. in EmpowerID

1. represent the organizational and geographical structure of an enterprise

1. , mirroring its operational model.

1. These optional, user-defined

1. locations create intuitive

1. and business-friendly nodes on a hierarchical

1. tree, making it easier for delegated users

1. to

1. interact with system resources.

1. Logical locations map to the physical locations of

1. resource systems and always reflect the resources

1. within that location. When mapping occurs, all

1. resources or objects

1. in the directory are assigned to their corresponding logical location

1. for delegation purposes. If a resource is removed from the external location,

1. it is also removed from the corresponding logical

1. location, and vice versa.
   

2. External Locations
   

1. External locations represent the actual locations of

1. resources

1. within resource systems.
   

2. All IT Systems

   The All IT Systems location is a default EmpowerID location

1. containing locations for all

1. IT systems

1. protected by EmpowerID

1. , including the EmpowerID system itself.

1. EmpowerID creates and dynamically maintains

1. locations

1. representing various resource systems, such as Active Directory, Microsoft Exchange, and Microsoft SharePoint,

1. which

1. are connected and managed through the inventory process. Resources inventoried from

1. managed resource

1. systems automatically exist in their corresponding EmpowerID location and

1. update if changed in the external system.

1. 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

1. a few key ways:

   • Due to

1. • their dynamic nature

1. • ,

1. • All IT Systems locations are hidden from

1. • role and location selectors

1. • for assigning Business Roles and

1. • locations to Person objects, except when using the actual structure of

1. • Active Directory as a business location

1. • .

1. • These locations are maintained automatically via inventory

1. • , moving when moved in the external system and

1. • deleted when deleted in the external system.

1. • All IT Systems locations are not mapped to external locations with the RBAC Mapper, as they automatically map

1. • 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.
     

2. Resource Systems Locations
   

1. Resource Systems Locations are

1. unique locations in EmpowerID

1. representing the structure of

1. various connected resource systems

1. . 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 where in which organizations prefer the use of utilizing Business Roles for managing their resources (, or would like to employ implement a combination blend of Resource–Based Resource-Based Access Control and Role–Based Role-Based Access Control), EmpowerID provides offers a polyarchical RBAC model that can capable of significantly enhance improving the management of those Business Roles over more traditional compared to conventional models. The term "Polyarchical RBAC" simply means indicates that the EmpowerID resource management model allows for provided by EmpowerID enables resources to be assigned allocated based on a combination of what a person does in an an individual's function within the organization (their Business Role) and where that person works their work location (their Location). This intersection of Business Roles and Locations allows for results in a much substantially smaller "role footprint" than is possible achievable with most approaches to RBAC and makes it possible to assign more precisely resources RBAC approaches, allowing for more precise resource assignment to multiple users in sharing the same role. As an example

To illustrate this point, let's consider examine how both models address tackle managing resource access needs for an employee common to banking institutions: the Teller.Generally speaking, it is understood requirements for a Teller, a position commonly found in banking institutions. It is generally acknowledged that most tellers perform the same similar tasks using the same types of comparable resources. So, using RBAC to manage the Therefore, managing access to those these resources sounds through RBAC appears relatively straight–forwarduncomplicated: You create a A "Teller" role is created, assign all tellers are assigned to the Teller that role, and then assign the necessary resources for tellers are allocated to the Teller role the resources tellers need. At this point, everything appears fine. Only one role is needed. But, what . Initially, everything seems satisfactory, with only one role required. However, complications may arise if the banking institution has branches located situated in multiple numerous cities, regions and , or even countries (such as would occur with e.g., branches in New York, London, and Sydney)? Although, by virtue of their job, . Although each teller needs requires access to a common shared pool of resources , by virtue of their location, each due to their job, they would also need resources outside the common poolunique to their location. Tellers in New York would need access to resources specific to New York, but not London or Sydney; tellers in London would need access to resources in London, but not New York or Sydney; and, tellers in Sydney would need access to resources in Sydney, but not New York or London. In this case, using 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 is problematic because doing so would create becomes problematic, as it would generate a "super role, " giving that grants each teller access to resources beyond their scope, presenting too great a purview, posing an excessive security risk and violating contravening the concept principle of minimum privilege. So, how does RBAC address tackle this issue?

Many typical A majority of conventional RBAC implementations would address resolve this problem challenge by creating separate establishing distinct roles for each teller location. ThusConsequently, tellers in London, New York, and Sydney would have possess their own roles, such as is depicted by the below demonstrated in the accompanying image.

While this may appear to be an adequate solution,

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

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

Whether you choose to use The decision to utilize Business Roles and Locations or not when delegating resources depends on the level is contingent upon the degree of immediate visibility you wish to maintain over desired for overseeing the assignment of those resources. Because Since these types of assignments occur transpire through the intersection of two separate distinct EmpowerID objects, the EmpowerID Business Role and the EmpowerID Location, auditing the access each individual has to resources each person has involves necessitates a few more details than occurs when additional details compared to using the Management Roles discussed in detail aboveelaborated upon earlier. Regardless of the method you choose, you should find that chosen approach, RBAC in EmpowerID is proves to be a powerful potent concept, fully able to meet the demands of the finest-grained capable of satisfying the requirements of even the most intricate security policies.