Traditional RBAC

RBAC, known in most Identity Management solutions as "Role-Based Access Control," is a framework designed to allow organizations to more efficiently manage permissions across applications and other protected IT resources. As such, the RBAC model attempts to mirror 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, managing permissions for each person falling into 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 RBAC, an organization can create a single role, "Standard Employee," 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."

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 with our IT resources?" and "How do we differentiate this for people with differing roles and resource needs?" For example, most organizations have the 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 the two roles. The Standard Employee role could have permissions assigned to it that allow those in the role to view "public profiles" only, while a Manager role could have permissions assigned to it that allow those in the role to view not only public profiles, but other more sensitive information as well.

The below image shows what this might look like conceptually. In the image, the access assigned to each role determines what a person in that role can do with another person's information. For our example, people in the Standard Employee role and the Manager role can both view public profile information (indicated by the green arrow flowing from the roles to the public profile information). However, the Manager role is differentiated in that it has additional access granted to it so that someone in that role has the ability to see absence reports (indicated by the green arrow flowing from the role to the absence reports), while a Standard Employee is denied that ability (indicated by the red arrow flowing from the role to the absence reports).

From a coding perspective, this could look like the following:

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

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

From this pseudo-code, we can see that the application determines the amount of employee information available to Standard Employees and Managers differs. If a user assigned to the Manager role logs in to 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 maintaining access controls for each individual in the Standard Employee role.

Often when discussing the benefits of RBAC, it is inevitable that groups come into the picture. Obviously, in a large environment, no one would maintain individual access controls for every single user. They would simply place those users into a group and then assign permissions to those groups. Thus, Standard Employees would be placed into one group and Managers would be placed into another group and each group would in turn be granted the appropriate levels of access to employee information. While this sounds like an equivalent solution, using AD groups as application roles is more challenging in that groups do not convey any real concept or relationship between the group and the resources and rights it grants. From an auditing and compliance perspective this can be seen as an unacceptable risk and an audit nightmare as auditors must rely on group naming convention schemes in order to attempt to discern what rights for which resources membership in the AD group grants. As organizations grow and add more users to more groups, the possibility of granting those users inappropriate access to resources for which the group had been originally assigned permissions, but were not apparent due to the limitations of naming conventions, becomes an increasing possibility.

RBAC as Resource-Based Access Control

As advantageous as traditional RBAC (Role-Based Access Control) can be for managing resources, it is not without challenges. One of the biggest of these occurs from the top-down approach to resource management inherent with Role-Based Access Control. As the name implies, Role-Based Access Control begins with a focus on roles: Let's define 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 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 smaller roles with overlapping and yet unique access needs, the IT department would need to revisit the application, making changes that could result in downtime, such as would occur if application code needed to be changed to incorporate the new roles.

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

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

Resource-Based Access Control changes 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 a highly flexible and granular framework by which explicit controls can be placed on every resource being protected. Returning to our Absence Reports example, Resource-Based Access Control would write the code as follows:

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

As can be seen, this pseudo-code does not define a particular role and does not concern itself with a user's identity. It simply checks to see if the user (whatever user) is authorized to view the report, showing or not showing it based on the results of that check. This allows organizations to assign and remove the ability to view the report to or from any user at any time without disruption or the need to rewrite the code block.

RBAC in EmpowerID

The EmpowerID RBAC model is one that reflects the Resource-Based Access Control paradigm; the platform is resource-centric, not role-centric. This allows organizations to focus on what they are protecting--their resources and the actions that can be performed against those resources. In EmpowerID, these "resource actions" are blocks of code known as "EmpowerID Operations." Each EmpowerID Operation is a protected code object that provides users with the ability to perform 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 must be delegated to users before they can do anything with a resource. For example, if you have an Absence Report, that report will have a number of EmpowerID Operations associated with it to protect each facet of that report from unauthorized activity. So, if you have a user named "Joe" and you want Joe to be able to see the report, you must grant Joe that ability by assigning him a specific Operation for the report that allows him to do so. If 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 him to perform that task. (You can do this at application runtime, causing no disruption to your users.)

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

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

Not only does the resource-specific model of EmpowerID's RBAC allow you to control access to each individual object protected by EmpowerID, it allows you to control access to the individual components of an object as well. In the case of the reports mentioned above, you can use Operations to secure sections or even fields on those reports considered more sensitive. Thus, you could grant Joe the ability 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 security policies.

In addition to assigning access to these reports to a single user like Joe, EmpowerID also allows you to assign access to groups, roles, or query-based collections of people. And, unlike the traditional RBAC approach, which limits role assignments to static chunks of code, EmpowerID resource-based assignments are dynamic. You can change the details of any assignment for any resource to any user at any time, all at application runtime.

Key Objects of the EmpowerID RBAC Model

In our discussion above, we provided an overview of RBAC in EmpowerID, showing how it deviates from the traditional 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 actions that can be performed against those resources. We saw that those actions are written as protected blocks of code, called EmpowerID Operations, and that only after defining those Operations does EmpowerID concern itself with the who. Moving from the what to the who involves more than simply creating a resource Operation and then assigning that Operation to a user. While at a high-level this is what occurs when a user is granted the ability to act against a resource, granting that ability involves the use of several other objects key to the EmpowerID RBAC model. Understanding those objects as defined by EmpowerID is essential to successfully using 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 belong to resource systems, which are the specific directories or IT systems in which they are contained. 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 have a resource entry in the EmpowerID Identity Warehouse that uniquely identifies the resource and the resource type from which the resource is derived. Resource types exist for all secured objects, including the applications and components of the EmpowerID system itself, as well as those resources belonging to an external system 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 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 through the assignment of external system rights and EmpowerID Operations specific to the 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 assigned to a user grants that user the ability to perform those operations and rights against the resource for which the Access Level pertains. They are application or resource type-specific definitions (known as "Access Level Definitions") of a set of rights and operations that make sense for 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.

Access Levels are necessary to delegations in EmpowerID and are the means by which a user receives access to resources. You cannot directly assign EmpowerID Operations or native system rights to users. Those assignments are made to Access Levels and then assigned to users.

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

As can be seen, 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 List operation. The List 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 List 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 "EmpowerID User Group B." This group can view the Daily Absence Report because it has been assigned an Access Level that contains the List operation that allows the Quarterly Absence Report to be viewed. (indicated by the green arrow flowing from the Access Level to the actor). However, EmpowerID User Group A does not have an Access Level with the List operation (indicated by the red arrow flowing from the Access Level to the actor) and therefore will not be able to see the report.

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 allow users the ability to edit the contents of the report, move the report, delete the report, and so on.

Without operations or rights, Access Levels are empty containers not capable of providing functional access to any resource object. These should be added to Access Levels before those roles are assigned to users. For information on how to do this, see Adding Operations to Access Level Definitions and Adding Rights to Access Level Definitions.

Access Level Assignment Scope

When assigning Access Levels to users, it is important to consider the scope of that assignment. The use of scopes enables you to place limits on the objects impacted by an Access Level assignment. When you apply a scope to an Access Level assignment, the assignee of that Access Level can only affect the resources that fall within the parameters of the scope. Scopes are used in conjunction with the location of a resource and can be of the following types:

Direct - A direct assignment grants users access to a specific Access Level for a specific resource object. This gives the assignee the ability to perform the actions defined by the operations and rights of the Access Level for that specific object. Thus, if you have a Access Level that grants administrative tasks against an Exchange Mailbox and directly assign that Access Level to a user, that user will have the ability to perform those tasks against that mailbox in the EmpowerID user interface as well as have the ability to approve those same tasks for users not authorized to do so.
By Location - Assignments scoped by location grant users the ability to affect all resources in or below the location of those resources in your organizational structure. Thus, if you have a Access Level that grants administrative tasks against Exchange Mailboxes and assign the Access Level to a user scoped by a location named "Sydney," that user will have the ability to perform those tasks against all mailboxes in or below the Sydney location. The assignee will not have any capabilities against any other mailboxes outside the Sydney location.
Relative Resources - Assignments scoped as relative limit the ability of the assignee to affect select resources to only those resources that are in relation to the assignee. These type of resources are only evaluated at runtime. Relative resources can be of the following types:
- Objects in the assignee's location and below - This allows the assignee the ability to affect select resources located in or below the location in which the assignee is located.
- Objects in the assignee's location and above - This allows the assignee the ability to affect select resources located in or above the location in which the assignee is located.
- The person object "Self" - This allows the assignee the ability to affect all resources related to their own person, such as any report objects they are authorized to see by virtue of their role within the organization.
Target RBAC Containers - RBAC Containers are collections of resources specific to certain EmpowerID actor types that can be used to make location-independent delegations. RBAC Containers include the following:
- Target Management Role - This allows the assignee the ability to affect all people belonging to the target role, regardless of the location of those people.
- Target Group - This allows the assignee the ability to affect all users accounts and people belonging to the target group, regardless of the location of those group members.
- Target SetGroup - This allows the assignee the ability to affect all resources belonging to the SetGroup, regardless of the location of those resources.

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

For more information on Access Levels see the following topics:

Management Roles

Although Access Levels serve as the buffer and conduit between users and resources, using them to directly assign resources to users, especially when dealing with 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 EmpowerID to track their assignments, using them to corporately manage delegations on a user-by-user basis can quickly become unpractical and time-consuming. For this reason, EmpowerID recommends assigning Access Levels to another type of role, known as the "Management Role," for delivering resources to users.

Management Roles are user-defined containers holding collections of Access Levels that have been packaged together into responsibility or job-based bundles to allow for the quick and easy bulk assignments of resources to resource users in a way that matches their job function. They are fully manageable EmpowerID objects that can be filled with 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 the EmpowerID Operations and/or native system rights added to each of those Access Levels. As containers of Access Levels, Management Roles depend on Access Levels to provide users with functional access to resources. Without Access Levels, Management Roles are nothing more than empty containers, incapable of providing any access to resources.

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

Management Roles and Definitions

In EmpowerID, Management Roles are children of Management Role Definitions. These Management Role Definitions allow multiple Management Roles to inherit a common set of Access Levels without the need to manage those assignments in each of the child Management Roles. This is helpful as it allows common access for a set of Management Roles to be defined and managed from one Management Role Definition, while also allowing 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 cannot be assigned to Management Role Definitions.

As an example of the relationship between the two, let's consider a default Management Role Definition and Management Role that EmpowerID provides out-of-the-box, the IT Administrator Management Role Definition and its child, the Enterprise IT Administrator Management Role. The IT Administrator Management Role Definition consists of 345 Access Levels that delegate 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 345 Access Levels, including the Initiator Access Level for the DeleteMailbox workflow, as well as 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 assigned to a user, that user will be able to 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 wide, additional Management Roles can be created from the Management Role Definition with their own unique Access Levels and scopes. Note that the primary difference between the Management Role Definition and the Management Role is scope. Management Role Definitions typically are set up without scoped assignments while Management Roles contain assignments scoped to any number of locations such as the "Anywhere" location.

Although EmpowerID provides default Management Role Definitions with Management Roles scope at the Enterprise level, most organizations will have policies requiring responsibilities like that of an IT Administrator be distributed across their enterprise to Management Roles with regional scope. Because Management Role Definitions can have as many child Management Roles as needed, a regional IT Administrator Management Role can be created for every region within an enterprise with Access Levels to scope the influence of those Management Roles accordingly. In this way, each of the regional IT Administrator Management Roles can affect resources in their region only. So for example, if you have organizational locations in "London," "New York," and "Sydney," you could create a London IT Administrator Management Role, aNew York IT Administrator Management Role and a Sydney IT Administrator Management Role from the one IT Administrator Management Role Definition and then assign those Management Roles to IT Administrators in London, New York, and Sydney, respectively.

The following image shows the relationship between the IT Administrator Management Role Definition and the above child Management Roles. Each child is a separate instance of the parent with additional Access Levels that scope the influence of the child to the intended location only. Thus, 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 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 Management Role. For example, the London IT Administrator Management Role can have a Access Level assignment to an EmpowerID workflow or page not needed 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.

Direct Static Assignment — Resources can be manually assigned to one or more EmpowerID Locations.
Implicit Assignment — Resources automatically belong to their resource system as well as to their actual "location" in that system. For example, Active Directory objects belong to their OUs and SharePoint objects belong to their site in the site tree.
RBAC Mapping — EmpowerID "logical" Locations can be created that map to one or more "physical" resource system locations. Once a mapping occurs, resources will automatically belong to any EmpowerID Location that is mapped to the actual resource system location of those resources.
Relative Location Assignment — Resources automatically belong to "relative" assignments that can be used with relative Access Levels.

EmpowerID provides a number of ways by which resources can belong to a location:

If a resource has been manually assigned to a location then it belongs to that location.
Locations are resources that belong to themselves as a location.
Person objects belong to the location of the person's primary Business Role and Location. If a person is assigned a secondary Business Role and Location, they Person object does not belong to the secondary location. Person objects also belong to any locations that their person is assigned to manually as a resource or through belonging to a Set Group.
If the resource has a path (currently user accounts, computers, Exchange mailboxes), the resource belongs to any locations that are mapped to an external location whose path matches the ParentPath field of the resource. When this is the case, it means that the external location is actually the parent OU of the object in the external directory.
If the resource is an account and it is owned by a person (joined), the user account belongs to the location of the person's primary Business Role and location.
If the resource is an Exchange Mailbox, and its account is assigned to a person, it belongs to the locations of the person's primary Business Role and location.
Special "Resource System Match" locations that represent an Account Store or Resource System to which the resources belong: These are designated as locations of ResourceSystemType = 12 and the ResourceSystem of the resource is the same as that set for the MatchingResourceSystemID of that location.
A resource belongs to any parent location of any location to which it has been assigned using the above criteria. The only exception to this rule is the location root node, Anywhere. Resources do not belong to this node unless they are direct children of that location or the resource has been explicitly assigned there.

Keeping with our London, New York, and Sydney theme, 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 the logical tree closely mirrors the naming of the 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.

Locations in EmpowerID comprise the following:

Logical Locations

Logical locations are those locations in EmpowerID that represent the organizational and geographical structure of an enterprise in a way that mirrors its operational model. Logical locations are optional, user-defined tools that can be used to create intuitive, business-friendly nodes on a hierarchical locations tree that offers delegated users the ability to more easily interact with system resources. These logical locations map to the physical locations of your resource systems and always reflect the resources inclusive to that location. When mapping occurs, all the resources or objects located in the directory are assigned to their corresponding logical location and can be used when delegating user rights. If a resource is removed from the external location, then it is removed from the corresponding logical location; if a resource is added to the external location, then it is added to the corresponding logical location.

External Locations

These are the locations of your resources in your resource systems.

All IT Systems

The All IT Systems location is a default EmpowerID location below which reside locations for all the IT systems that EmpowerID protects, including the EmpowerID system itself. Within this location, EmpowerID creates and dynamically maintains the locations that represent the various resource systems, such as Active Directory, Microsoft Exchange, and Microsoft SharePoint, to which EmpowerID connects and manages via the inventory process. Resources inventoried from the managed resource system automatically exist in their corresponding EmpowerID location and their EmpowerID location updates if it changes in the external system. Because these locations map to actual resources, the internal structure of these locations should not be reorganized or modified.

These locations differ from standard EmpowerID locations in the following few key ways:

Due to the dynamic nature of these locations, the All IT Systems locations are hidden from the role and location selectors used to assign Business Roles and locations to Person objects and are not intended to be used for those purposes. An exception to this is when it is desirous to utilize the actual structure of the Active Directory as a business location rather than recreating it in a logical representation. In this case, it is necessary to map your directory.
These locations are maintained automatically via inventory. They move when moved in the external system and are deleted when deleted in the external system.
These 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.

Resource Systems Locations

These are special locations in EmpowerID that represent the structure of the various resource systems to which EmpowerID is connected. 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.

For task-based help on mapping locations, see Mapping 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).

The use of Business Roles and Locations for resource management is an option for those who prefer to manage resources with more of a role-based approach; however, the combination of a Business Role with a Location does not create a single manageable object and therefore can be less conspicuous in conveying the amount of access to resources someone in that Business Role and Location may or may not have. The preferred role in EmpowerID is the Management Role.

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.

For more information on SetGroups, see Query-Based Collections Overview (Sets and Set Groups) and Setting up Query-Based Collections.

Polyarchical RBAC

For situations where organizations prefer the use of Business Roles for managing their resources (or would like to employ a combination of Resource-Based Access Control and Role-Based Access Control), EmpowerID provides a polyarchical RBAC model that can significantly enhance the management of those Business Roles over more traditional models. "Polyarchical RBAC " simply means that the EmpowerID resource management model allows for resources to be assigned based on a combination of what a person does in an organization (their Business Role) and where that person works (their Location). This intersection of Business Roles and Locations allows for a much smaller "role footprint " than is possible with most approaches to RBAC and makes it possible to assign more precisely resources to multiple users in the same role. As an example, let's consider how both models address managing resource access needs for an employee common to banking institutions: the Teller.

Generally speaking, it is understood that most tellers perform the same tasks using the same types of resources. So, using RBAC to manage the access to those resources sounds relatively straight-forward: You create a "Teller " role, assign all tellers to the Teller role, and then assign to the Teller role the resources tellers need. At this point, everything appears fine. Only one role is needed. But, what if the banking institution has branches located in multiple cities, regions and even countries (such as would occur with branches in New York, London, and Sydney)? Although, by virtue of their job, each teller needs access to a common pool of resources, by virtue of their location, each would also need resources outside the common pool. 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 the same Teller role for all tellers is problematic because doing so would create a "super role, " giving each teller access to resources beyond their scope, presenting too great a security risk and violating the concept of minimum privilege. So how does RBAC address this?

Many typical RBAC implementations would address this problem by creating separate roles for each teller location. Thus, tellers in London, New York, and Sydney would have their own roles, such as is depicted by the below image.

While this may appear to be an adequate solution, creating separate roles for each teller location can quickly become unmanageable, leading to role bloat and eventual confusion over which roles have access to which resources. Simply envision tellers working for the same banking institution with branches located in every major city throughout the world.

As mentioned above, the polyarchical model of EmpowerID allows you to significantly reduce an organization's role footprint by allowing 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 role bloat using only one Teller Business Role without creating a "super role. " This is possible because EmpowerID allows you to differentiate the resources assigned to a Business Role based on the location of those resources. In this way, tellers in London, New York, and Sydney can all have the same Business Role without accessing each others resources. Thus EmpowerID would address the above role situation as follows:

Whether you choose to use Business Roles and Locations or not when delegating resources depends on the level of immediate visibility you wish to maintain over the assignment of those resources. Because these types of assignments occur through the intersection of two separate EmpowerID objects, the EmpowerID Business Role and the EmpowerID Location, auditing the access to resources each person has involves a few more details than occurs when using the Management Roles discussed in detail above. Regardless of the method you choose, you should find that RBAC in EmpowerID is a powerful concept, fully able to meet the demands of the finest-grained security policies.

In this article

Browser not supported