Date: Fri, 29 Mar 2024 08:06:08 +0000 (UTC) Message-ID: <1763146274.227.1711699568051@5a037a9133dd> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_226_74066541.1711699568051" ------=_Part_226_74066541.1711699568051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
RBAC, known in most Identity Management solutions as "Role-Based Access = Control," is a framework designed to allow organizations to more efficientl= y manage permissions across applications and other protected IT resources. = As such, the RBAC model attempts to mirror real-world organizational struct= ure by recognizing that most individuals within organizations perform tasks= against resources related to the function or job title they hold within th= at organization, accessing resources in a behavior-specific way, and that m= ore than one can have the same role. For example, an organization could hav= e 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 thi= s 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 usi= ng RBAC, an organization can create a single role, "Standard Employee," def= ine how that role is to "behave" in an IT environment, and then place all s= tandard employees into that Standard Employee role. In this way, permission= s management is reduced from "the many to the one."
Traditional approaches to RBAC provide a framework that allows organizat= ions to ask and answer, "What do we want to allow people with this job titl= e or role to be able to do with our IT resources?" and "How do we different= iate this for people with differing roles and resource needs?" For example,= most organizations have the Standard Employees mentioned above and the Man= agers of those Standard Employees might both need to interact with informat= ion about other people within their organization. However, in lieu of the r= esponsibilities associated with what they do in that organization, the amou= nt of interaction they have with that information should differ qualitative= ly. The use of RBAC allows the differences in that interaction to be define= d through the assignment of varying levels of permissions for the two roles= . The Standard Employee role could have permissions assigned to it that all= ow those in the role to view "public profiles" only, while a Manager role c= ould have permissions assigned to it that allow those in the role to view n= ot only public profiles, but other more sensitive information as well.
The below image shows what this might look like conceptually. In the ima= ge, 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 St= andard Employee role and the Manager role can both view public profile info= rmation (indicated by the green arrow flowing from the roles to the public = profile information). However, the Manager role is differentiated in that i= t 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 t= he role to the absence reports), while a Standard Employee is denied that a= bility (indicated by the red arrow flowing from the role to the absence rep= orts).
From a coding perspective, this could look like the following:
=
p>
if (user.= role =3D=3D StandardEmployee) this.application.show(Employee.PublicProfile) else if (user.role =3D=3D Manager) this.application.show(Employee.PublicProfile + Employee.AbsenceReport)
From this pseudo-code, we can see that the application determines the amoun=
t of employee information available to Standard Employees and Managers diff=
ers. If a user assigned to the Manager role logs in to the application, tha=
t user is granted the ability to view the public profiles of employees as w=
ell 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 th=
e management tasks involved with user access. Simply imagine the headaches =
involved with maintaining access controls for each individual in the Standa=
rd 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 mai= ntain individual access controls for every single user. They would simply p= lace 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 ap= propriate levels of access to employee information. While this sounds like = an equivalent solution, using AD groups as application roles is more challe= nging 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 com= pliance perspective this can be seen as an unacceptable risk and an audit n= ightmare 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 w= hich the group had been originally assigned permissions, but were not appar= ent due to the limitations of naming conventions, becomes an increasing pos= sibility.
As advantageous as traditional RBAC (Role-Based Access Control) can be f= or managing resources, it is not without challenges. One of the biggest of = these occurs from the top-down approach to resource management inherent wit= h 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, re= quiring much effort to keep it in sync with evolving organizational policie= s. If it is later decided that the Manager role mentioned above is too enco= mpassing and needs to be broken down into a number of smaller roles with ov= erlapping and yet unique access needs, the IT department would need to revi= sit 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 =3D=3D DepartmentManager||user.role =3D=3D HRManager|| ...) this.application.show(employee.AbsenceReports)
And with each new similar change to policy, the process would repeat its= elf. The IT team would need to revisit the application, investing significa= nt resources each time the smallest change occurs. But beyond this, writing= role checks into code as the above does lacks the transparency necessary f= or maintaining a useful audit trail. As there is no clear external link bet= ween the Absence Reports resource and the roles with access to it, assignme= nts like this cannot be audited. Over the passage of time, exactly what res= ources each role can access becomes lost to everyone. The EmpowerID RBAC mo= del was designed with these issues in mind to allow organizations to implem= ent just such changes with full visibility and without requiring heavy inve= stments by an IT team. This model is fundamentally different in that it app= roaches the management of resources from the bottom-up using the methodolog= ies of a way known as "Resource-Based Access Control."
Resource-Based Access Control changes the questions being asked to refle= ct more accurately what it is that security policies are designed to do: pr= otect resources. Thus, Resource-Based Access Control begins with asking what needs to be protected, not who can have access to it. W= hile this may sound semantic, approaching access control from a resource-dr= iven perspective yields a highly flexible and granular framework by which e= xplicit 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 d= oes not concern itself with a user's identity. It simply checks to see if t= he user (whatever user) is authorized to view the report, showing or not sh= owing it based on the results of that check. This allows organizations to a= ssign 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.
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 Operation= s." Each EmpowerID Operation is a protected code object that provides users= with the ability to perform a task against a resource object, such as addi= ng a user to a group, creating a mailbox, or viewing a report. Each of thes= e actions must be delegated to users before they can do anything with a res= ource. 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 abil= ity 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 per= form that task. (You can do this at application runtime, causing no disrupt= ion to your users.)
In addition, Operation assignments are specific to one resource object o= nly, allowing for the easy implementation of resource-specific management s= trategies. 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 de= legation is performed using inheritance or a query-based collection of repo= rts.
In the below image, there are two prot= ected resource objects on the right side of the image =E2=80=94 an Absence = Report and a Finance Report =E2=80=94 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 Em= powerID (represented by the green arrow with the Operations flowing from Jo= e 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 i= n front of the Finance Report). He cannot even see that a Finance Report ex= ists 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 allo= ws 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 secu= re sections or even fields on those reports considered more sensitive. Thus= , you could grant Joe the ability to view and edit the Absence Report, whil= e at the same time denying him the ability to do so with any component on t= hat report. You can therefore control access to meet the demands of the fin= est-grained security policies.
In addition to assigning access to these reports to a single user like J= oe, EmpowerID also allows you to assign access to groups, roles, or query-b= ased collections of people. And, unlike the traditional RBAC approach, whic= h limits role assignments to static chunks of code, EmpowerID resource-base= d assignments are dynamic. You can change the details of any assignment for= any resource to any user at any time, all at application runtime.
In our discussion above, we provided an overview of RBAC in EmpowerID, s= howing how it deviates from the traditional role-based security model. In d= oing 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 tho= se roles can or cannot do in an environment, EmpowerID begins with defining= resources and the actions that can be performed against those resources. W= e saw that those actions are written as protected blocks of code, called Em= powerID Operations, and that only after defining those Operations does Empo= werID concern itself with the who. Moving from the what to the who involves= more than simply creating a resource Operation and then assigning that Ope= ration 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 involv= es the use of several other objects key to the EmpowerID RBAC model. Unders= tanding those objects as defined by EmpowerID is essential to successfully = using the platform to manage your resources. The following provides definit= ions for these objects, as well as further definitions for the objects disc= ussed above, showing how each object fits together to provide rich resource= security.
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 syste= ms in which they are contained. Resource systems can include Active Directo= ry domains, LDAP directories, HR systems, Microsoft Exchange Organizations,= SharePoint Farms, custom applications, and even the EmpowerID system itsel= f. All objects of any type that are managed by EmpowerID in a secure fashio= n have a resource entry in the EmpowerID Identity Warehouse that uniquely identifies the res= ource and the resource type from which the resource is derived. Resource ty= pes exist for all secured objects, including the applications and component= s of the EmpowerID system itself, as well as those resources belonging to a= n external system protected by EmpowerID.
Each resource object is cataloged by resource type to provide support fo= r the different properties associated with those resource types and to allo= w for a consistent interface to manage those objects in EmpowerID. Generall= y speaking, the nomenclature used for a resource object matches that of its= resource type. Thus, Exchange Mailbox objects belong to the Exchange Mailb= ox resource type, SharePoint Web Sites belong to the SharePoint Webs resour= ce type and so on. Whenever a user is granted access to one of these Identi= ty Warehouse objects and makes changes to it, EmpowerID passes those change= s 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 res= ource being accessed via EmpowerID objects known as "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 assi= gnable object that when assigned to a user grants that user the ability to = perform those operations and rights against the resource for which the Acce= ss Level pertains. They are application or resource type-specific definitio= ns (known as "Access Level Definitions") of a set of rights and operations = that make sense for resources derived from a particular resource system, su= ch as Exchange Mailboxes, User Accounts, AD Security Groups, and SharePoint= sites. Each of these resource types would have its own set of Access Level= s defined with different combinations of rights (if applicable) and/or Empo= werID Operations that would apply to each object in that reso= urce system.
For example, an Access Level for the Exchange Mailbox resource type defi=
ned with an EmpowerID Operation that allows mailboxes to be deleted will gr=
ant any user the ability to delete any mailbox for which the user is assign=
ed the Access Level. This assignment can be as broad as to include all mail=
boxes within an organization or as limited as to include only a single mail=
box. 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 a=
re defined and managed at the definition of the Access Level for the resour=
ce.
Access Levels are necessary to delegat= ions in EmpowerID and are the means by which a user receives access to reso= urces. You cannot directly assign EmpowerID Operations or native system rig= hts 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. T= he operations and/or rights assigned to Access Levels (via their Access Lev= el 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 Quarte=
rly Absence Report, a group of users, as well as an Access Level for the re=
port. The Access Level is comprised of a single EmpowerID Operation: the Li=
st operation. The List operation is a code action that can be executed agai=
nst a specific report object allowing that report to be viewed in EmpowerID=
. (This is represented by the green arrow flowing from the List operation t=
o the Quarterly Absence Report.) Given the nature of the report, we want on=
ly certain individuals to be able to view it. In our image, those individua=
ls are represented by "EmpowerID User Group B." This group can view the Dai=
ly Absence Report because it has been assigned an Access Level that contain=
s 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 Lis=
t operation (indicated by the red arrow flowing from the Access Level to th=
e 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 appropri=
ate rights and operations. Thus, for the Quarterly Absence Report, you coul=
d create additional Access Levels, adding operations to those Access Levels=
to allow users the ability to edit the contents of the report, move the re=
port, delete the report, and so on.
Without operations or rights, Access L= evels are empty containers not capable of providing functional access to an= y resource object. These should be added to Access Levels before those role= s 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.
When assigning Access Levels to users, it is important to consider the s= cope of that assignment. The use of scopes enables you to place limits on t= he objects impacted by an Access Level assignment. When you apply a scope t= o an Access Level assignment, the assignee of that Access Level can only af= fect 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 foll= owing types:
The following image shows Access Level assignments granted to three diff= erent 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, m= embers 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:
Although Access Levels serve as the buffer and conduit between users and= resources, using them to directly assign resources to users, especially wh= en dealing with large numbers of users, is not recommended. Aside from the = benefits of the granular access controls Access Levels place on resources a= nd the ability of EmpowerID to track their assignments, using them to corpo= rately manage delegations on a user-by-user basis can quickly become unprac= tical and time-consuming. For this reason, EmpowerID recommends assigning A= ccess Levels to another type of role, known as the "Management Role," for d= elivering resources to users.
Management Roles are user-defined containers holding collections of Acce= ss Levels that have been packaged together into responsibility or job-based= bundles to allow for the quick and easy bulk assignments of resources to r= esource users in a way that matches their job function. They are fully mana= geable EmpowerID objects that can be filled with any number of Access Level= s for any resource type and assigned to users to allow them to act upon eac= h resource in a way commensurate with the EmpowerID Operations and/or nativ= e system rights added to each of those Access Levels. As containers of Acce= ss Levels, Management Roles depend on Access Levels to provide users with f= unctional access to resources. Without Access Levels, Management Roles are = nothing more than empty containers, incapable of providing any access to re= sources.
The following image demonstrates the relationship between resources, Man= agement Roles, Access Levels and users in EmpowerID. As can be seen, the Ma= nagement 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 passe= d to the users with the Management Role.
In EmpowerID, Management Roles are children of Management Role Definitio= ns. These Management Role Definitions allow multiple Management Roles to in= herit a common set of Access Levels without the need to manage those assign= ments in each of the child Management Roles. This is helpful as it allows c= ommon access for a set of Management Roles to be defined and managed from o= ne Management Role Definition, while also allowing each child Management Ro= le to be customized with additional Access Levels for access to resources u= nique to that Management Role. Management Role Definitions differ from Mana= gement Roles in that users cannot be assigned to Management Role Definition= s.
As an example of the relationship between the two, let's consider a defa= ult Management Role Definition and Management Role that EmpowerID provides = out-of-the-box, the IT Administrator Management Role Definition an= d its child, the Enterprise IT Administrator Management Role. The = IT Administrator Management Role Definition consists of 345 Access Levels t= hat delegate access to the general pages, workflows, and other resources th= at IT Administrators might need, such as the Initiator Access Leve= l for the DeleteMailbox request workflow. (This Access Level allow= s users to run the DeleteMailbox workflow, which is used to delete mailboxe= s and the AD user account associated with the mailbox.) As a child of the I= T Administrator Management Role Definition, the Enterprise IT Administrator= Management Role inherits each of those 345 Access Levels, including the In= itiator Access Level for the DeleteMailbox workflow, as well as contains ei= ght additional Access Levels scoped at the "Anywhere" location, giving the = Management Role enterprise-wide capabilities against the resources for whic= h 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 object= s related to the workflow regardless of their location within the enterpris= e. For example, two of the Access Levels scoped at the Anywhere location ar= e the EmpowerID Administrator Access Level for the User Account resource ty= pe and the EmpowerID Administrator Access Level for the Exchange Mailbox re= source type. These Access Levels allow all EmpowerID Operations that can be= performed against both user accounts and mailboxes in EmpowerID to be acco= mplished by anyone with the Access Level. Thus, an assignee of this Managem= ent Role will have the ability to run the DeleteMailbox workflow against an= y 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 R= ole. As the parent, the Management Role Definition passes all of its Access= Levels to the child Management Role, which contains additional Access Leve= ls to give it scope. While the scope of this particular Management Role is = enterprise wide, additional Management Roles can be created from the Manage= ment Role Definition with their own unique Access Levels and scopes. Note t= hat the primary difference between the Management Role Definition and the M= anagement Role is scope. Management Role Definitions typically are set up w= ithout 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 Man= agement Roles scope at the Enterprise level, most organizations will have p= olicies requiring responsibilities like that of an IT Administrator be dist= ributed across their enterprise to Management Roles with regional scope. Be= cause Management Role Definitions can have as many child Management Roles a= s needed, a regional IT Administrator Management Role can be created for ev= ery region within an enterprise with Access Levels to scope the influence o= f those Management Roles accordingly. In this way, each of the regional IT = Administrator Management Roles can affect resources in their region only. S= o for example, if you have organizational locations in "London," "New York,= " and "Sydney," you could create a London IT Administrator Managem= ent Role, aNew York IT Administrator Management Role and a Syd= ney IT Administrator Management Role from the one IT Administrator Man= agement Role Definition and then assign those Management Roles to IT Admini= strators 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 sc= ope the influence of the child to the intended location only. Thus, assigne= es 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 Administ= rator Management Role can only affect resources in Sydney.
Locations play an important part in the EmpowerID RBAC model: In order t= o 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 ac= cess to those resources. This occurs through the use of two types of Locati= on trees: The "External Locations" tree and the "EmpowerID Locations" tree.= The External Locations tree is a representation of the location of resourc= es in the actual resource systems to which EmpowerID is connected. EmpowerI= D 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 represent= ation of the organizational and geographical structure of an enterprise tha= t 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 dynam= ic link through it to the actual locations of the resources in the resource= system. Once the External Locations tree is populated, you can create Empo= werID Locations, map them to the External Locations and then use those Empo= werID Locations for assigning the resources in your resource systems to the= users in your organization.
EmpowerID provides a number of ways by which resources can belong to a l= ocation:
Keeping with our London, New York, and Sydney theme, the below image sho= ws an example of what these trees could look like in EmpowerID once a resou= rce 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 locatio= ns in the External Locations tree to locations in the EmpowerID Locations t= ree indicate a mapping of those locations. This means that you can manage t= he resources in those external locations from their mapped counterparts in = the EmpowerID Locations tree.
Locations in EmpowerID comprise the following:
Logical locations are those locations in EmpowerID that represent the or= ganizational and geographical structure of an enterprise in a way that mirr= ors its operational model. Logical locations are optional, user-defined too= ls that can be used to create intuitive, business-friendly nodes on a hiera= rchical locations tree that offers delegated users the ability to more easi= ly interact with system resources. These logical locations map to the physi= cal locations of your resource systems and always reflect the resources inc= lusive to that location. When mapping occurs, all the resources or objects = located in the directory are assigned to their corresponding logical locati= on and can be used when delegating user rights. If a resource is removed fr= om the external location, then it is removed from the corresponding logical= location; if a resource is added to the external location, then it is adde= d to the corresponding logical location.
These are the locations of your resources in your resource 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 dy= namically maintains the locations that represent the various resource syste= ms, such as Active Directory, Microsoft Exchange, and Microsoft SharePoint,= to which EmpowerID connects and manages via the inventory process. Resourc= es inventoried from the managed resource system automatically exist in thei= r corresponding EmpowerID location and their EmpowerID location updates if = it changes in the external system. Because these locations map to actual re= sources, the internal structure of these locations should not be reorganize= d or modified.
These locations differ from standard EmpowerID locations in the followin= g few key ways:
These are special locations in EmpowerID that represent the structure of= the various resource systems to which EmpowerID is connected. These locati= ons are contained under the All IT Systems node of the EmpowerID Locations = tree.
SetGroups are made up of Sets, which are code-based or LDAP-based querie= s resulting in collections of people or resources. SetGroups are not locati= ons themselves, but can be mapped to one or more locations so that the reso= urces belonging to the SetGroup belong to any mapped locations.
For task-based help on mapping locations, see Mappin= g Locations.
In EmpowerID, RBAC actors are the "who" of EmpowerID's RBAC model. Actor= s are those resources in your environment that can receive Access Level Ass= ignments to perform some type of action against other resources. While RBAC= actors can be Person objects, accounts, groups, SetGroups, Management Role= s, and Business Roles and Locations (in that each of these resource types c= an act against other resource types), the actions performed is always accom= plished 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.
In EmpowerID, a person is an object in the EmpowerID SQL-based Identity =
Warehouse that links together the user accounts, the permissions assignment=
s, the audit history, and the management policies associated with that pers=
on, in whatever directories they may be located. Persons are the true actor=
s in EmpowerID in that all actions performed via the delegations granted by=
Access Level assignments and Management Role assignments, regardless of wh=
ich actor type received the delegations, are ultimately performed by an Emp=
owerID Person. Thus, the EmpowerID Person is the base identity in the Empow=
erID RBAC model and is necessary for RBAC assignments to occur, regardless =
of which actor type is the recipient of the assignment. In other words, ass=
ignments of resources to accounts, groups, Management Roles, SetGroups or B=
usiness Roles and Locations will only have effect if those objects are link=
ed to EmpowerID Persons. If a user does not have an EmpowerID identity, tha=
t user cannot be the recipient of an RBAC assignment. Users without corresp=
onding EmpowerID Person objects will simply not be able to affect resources=
in EmpowerID. The only exception to this rule are the few workflows config=
ured 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 dispar=
ate systems into one manageable object that can be used to authenticate tho=
se users in those systems without needing to leave EmpowerID.
A group is a collection of user accounts residing in a directory outside= of EmpowerID. In EmpowerID, these user accounts are linked to the EmpowerI= D Person objects that own them, which makes groups simply collections of ac= counts that resolve to people. This allows EmpowerID to support using group= s to assign permissions across directories and IT systems. In essence, an a= ssignment of rights to a group grants those rights to the Person objects th= at own the member user accounts. This means that groups can be used as coll= ections of Person objects for assignment and the group is not required to b= e an object in the same directory (or alternate directory technology). For = instance, Active Directory groups can be used to grant permissions in any r= esource system (such as HR systems and custom applications, etc).
A Business Role is a user-defined hierarchical container for a grouping = of EmpowerID Person objects that can be used for delegating access to resou= rces 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 a= nd location within an organization, allowing for polyarchical RBAC resource= assignments. This is implemented in EmpowerID via tree interfaces (with in= heritance) that allow for the intersection of Business Roles with Locations= to support the following:
The use of Business Roles and Locations for resource management is an op= tion for those who prefer to manage resources with more of a role-based app= roach; 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 Ma= nagement Role.
As discussed above, Management Roles are bundles of Access Levels packag= ed together to allow for the quick and easy bulk assignment of resources to= people in a way that matches their job function.
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 d=
ynamically assign resources. SetGroups can be both an EmpowerID Actor type =
as well as a simple resource type, depending on the objects contained withi=
n the SetGroup. Therefore to use SetGroups as an EmpowerID Actor capable of=
performing tasks against other resources, the SetGroup must return collect=
ions of people.
For more information on SetGroups, see Query-Based Collections Overview (Sets and Set Groups) and Setting up Query-Based Collections.
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 th= ose Business Roles over more traditional models. "Polyarchical RBAC " simpl= y means that the EmpowerID resource management model allows for resources t= o be assigned based on a combination of what a person does in an organizati= on (their Business Role) and where that person works (their Location). This= intersection of Business Roles and Locations allows for a much smaller "ro= le footprint " than is possible with most approaches to RBAC and makes it p= ossible to assign more precisely resources to multiple users in the same ro= le. As an example, let's consider how both models address managing resource= access needs for an employee common to banking institutions: the Teller.= p>
Generally speaking, it is understood that most tellers perform the same = tasks using the same types of resources. So, using RBAC to manage the acces= s to those resources sounds relatively straight-forward: You create a "Tell= er " role, assign all tellers to the Teller role, and then assign to the Te= ller role the resources tellers need. At this point, everything appears fin= e. Only one role is needed. But, what if the banking institution has branch= es located in multiple cities, regions and even countries (such as would oc= cur 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 virtu= e 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 ac= cess to resources in Sydney, but not New York or London. In this case, usin= g the same Teller role for all tellers is problematic because doing so woul= d create a "super role, " giving each teller access to resources beyond the= ir 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 i= mage.
While this may appear to be an adequate solution, creating separate role= s for each teller location can quickly become unmanageable, leading to role= bloat and eventual confusion over which roles have access to which resourc= es. Simply envision tellers working for the same banking institution with b= ranches located in every major city throughout the world.
As mentioned above, the polyarchical model of EmpowerID allows you to si=
gnificantly reduce an organization's role footprint by allowing resources t=
o be assigned to users based on a combination of their Business Roles and L=
ocations. This approach makes it possible to address the above role bloat u=
sing only one Teller Business Role without creating a "super role. " This i=
s possible because EmpowerID allows you to differentiate the resources assi=
gned to a Business Role based on the location of those resources. In this w=
ay, 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 deleg= ating resources depends on the level of immediate visibility you wish to ma= intain over the assignment of those resources. Because these types of assig= nments occur through the intersection of two separate EmpowerID objects, th= e EmpowerID Business Role and the EmpowerID Location, auditing the access t= o resources each person has involves a few more details than occurs when us= ing the Management Roles discussed in detail above. Regardless of the metho= d 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.