Direct
Direct assignments scope access to a single resource of a specific resource type, giving the actor receiving the assignment the ability to perform the operations and rights of the Access Level against that resource. An example would be assigning the Help Desk Access Level for the user account owned by "Ruth" to an EmpowerID Person named "Bob." In this example, user account is the resource type, the user account owned by Ruth is the resource, and the EmpowerID Person Bob is the actor. With this type of Access Level assignment, Bob can perform Help Desk operations against Ruth's user account, but not another.
By Location
By-Location assignments scope access to all resources of a specific resource type in a designated location, giving the actor receiving the assignment the ability to perform the operations and rights of the Access Level against those particular resources. An example would be assigning the Help Desk Access Level for all user accounts in Toronto to the Toronto Help Desk group. In this example, user account is the resource type, the user accounts in Toronto are the resources, and the Toronto Help Desk group is the actor. With this type of Access Level assignment, all members of the group can perform Help Desk operations against all the user accounts in Toronto (as well as in any locations for which Toronto is the parent), but not in any other locations.
Relative
Relative assignments scope access to all resources of a specific type that belong to the same location as the actor receiving the assignment. An example would be assigning the Help Desk Access Level for all user accounts in Bob's location to Bob. In this example, user account is the resource type, the user accounts in Bob's location are the resources, and the EmpowerID Person Bob is the actor. With this type of Access Level assignment, Bob can perform Help Desk operations against all the user accounts in his location (as well as in any locations for which his location is the parent), but not in any other locations.
Design Considerations
When designing a delegation model, it is important to consider the projection and enforcement process that EmpowerID uses to manage the security of your resources. As mentioned above, these delegations can be done by selecting one or more EmpowerID actor types and granting them access directly, by location, or via a role assignment. The access type chosen in the delegation will impact the number of domain local groups created later for the Access Levels that get enforced. Here are few things to consider when deciding your course of action:
As a best practice, you should use roles whenever possible. Roles are more generic and can group a large number of delegations to protected resources, creating only one EmpowerID Access Level Group in each domain for all members of the role as opposed to the creation of a domain local group (EmpowerID Access Level Group) that occurs for each direct assignment. In addition, using roles provides an extra layer of abstraction between the actor and the delegation, making management easier, and reporting and auditing more clear.
Location delegations are also a good choice and they will also result in a single group per domain; however, you can potentially have more groups than you would by using Management Roles.
The least recommended method for delegating access to resources is using direct assignments. Direct assignments should only be used to cover the delegation "exceptions" that cannot be met by using roles or location delegations. The reason this approach should be used sparingly is that it can become cumbersome if you are managing a large number of Access Levels because each direct assignment results in the creation of a separate domain local group for enforcement to the external system.