Projection and Enforcement

Owned by Universal Importer for Confluence
Last updated: Nov 12, 2018 by Patrick Parker

In addition to inventorying accounts in connected account stores, creating EmpowerID identities for those accounts, and fully managing the attributes of those identities, EmpowerID has the ability to use those identities to control access to the resources in native resource systems, like Microsoft Exchange. This ability is known as "Enforcement and Resource Role Reconciliation or Projection" and is a feature of the EmpowerID RBAC model. This model consists of processes capable of determining the net resultant access to resources each EmpowerID Person should have based on their Access Level assignments. This resultant access includes any native resource system rights granted by virtue of those Resource Role assignments. EmpowerID delivers these rights to your native resource systems to allow users capabilities in those systems outside of EmpowerID. This means that if "Bob" is assigned an Access Level that grants him a "Full Control" right for a specific Exchange mailbox, "Bob" will be able to open and use that mailbox from directly within Microsoft Outlook.

EmpowerID controls this type of access by creating special domain local groups known as "Resource Role Groups" or "EmpowerID Groups" for each type of Access Level assignment with native rights that occurs in EmpowerID. EmpowerID then controls who can be a member of each Resource Role Group based on whether or not they have been granted an appropriate Resource Role assignment. The number and type of groups created is highly optimized to avoid the possibility of token bloat. These assignment types and how EmpowerID responds to them within the context of Resource Role Groups is as follows:

  • Direct Assignments - Whenever an Access Level with rights is directly assigned to an EmpowerID actor, EmpowerID creates a Resource Role Group, prefixing it with "EID_" to denote it as being derived from a direct assignment, and places it as an object in a specified OU. This occurs only if the recipient of the Resource Role assignment can be linked to an EmpowerID Person owning a user account that can be added to a domain local group based on a trust relationship.
  • Management Role Assignments - Whenever an Access Level is assigned to an EmpowerID actor via a Management Role assignment, EmpowerID creates a Resource Role Group, prefixing it with "EIDM_" to denote it as being derived from a Management Role assignment, and places it as an object in a specified OU. One Resource Role Group is created in each account store for a Management Role if needed.
  • By Location Assignments - Whenever an Access Level is assigned to an EmpowerID actor via a "By Location" assignment, EmpowerID creates a Resource Role Group, prefixing it with "EIDZ_" to denote it as being derived from a By Location assignment. To minimize the possibilities of logon token bloat, EmpowerID creates only one Resource Role Group for the assignment itself and not for all the specific Access Levels that could exist below the location via inheritance.

When Enforcement and Resource Role Reconciliation is enabled for an Active Directory account store with resource systems, EmpowerID begins the process of permissions enforcement by looking for any Access Levels that have been defined with at least one right, flagged as enabled, and directly assigned to at least one person with an account that can be added to a domain local group. If EmpowerID finds Access Levels meeting these criteria, the EmpowerID Worker Role marks the Access Level as "Queued for Projection" and creates a new Resource Role Group in Active Directory with all possible accounts added to its membership. Once the Resource Role Group is created, the Worker Role marks the Access Level as "Queued for Enforcement" and stores the domain local group information in the Access Level.

Once an Access Level is marked as "Queued for Enforcement," the EmpowerID Worker Role calls the Enforcement Job to grant and/or revoke permissions within the native resource system for each member of the Resource Role Group as appropriate. At the next iteration of the Inventory Job, EmpowerID retrieves the permissions of the Resource Role Groups in Active Directory and writes them to the Windows Principal ResourceType table of the Identity Warehouse. These values are then used during the next iteration of the Enforcement and Projection process.

This can be depicted in the following way:



 

  1. For EmpowerID to manage native permissions for a resource system in this way, the Rights Enforcement for Resource Role Groups setting for the resource system must be set to allow enforcement, and at least one EmpowerID server must be running the EmpowerID Worker Role Windows service with the Resource Role Reconciliation and Rights Enforcement jobs enabled on that server. Rights Enforcement for Resource Role Groups can be configured in one of the following four ways:

  2. A Person is assigned an Access Level that grants that Person Full Control for a mailbox in an EmpowerID workflow.
  3. Upon discovering the new Access Level assignment— and in accordance with the Resource Role Reconciliation schedule—the EmpowerID Worker Role initiates the Resource Role Reconciliation Job for the Active Directory account store, calling the LDAP Management Host to create the new Resource Role Group in Active Directory.
  4. The LDAP Management Host creates the new Resource Role Group in Active Directory. The group is prefixed with either "EID_" if the right is derived from a direct Resource Role assignment, "EIDM_" if the right is derived from a Management Role assignment, or "EIDZ_" if the right is derived from a By Location assignment.
  5. The EmpowerID Worker Role initiates the Rights Enforcement Job in accordance with the schedule for that job to push the Full Control right conferred by the Access Level assignment to the native Exchange resource system via the Exchange Management Host on the EmpowerID Agent.
  6. The Exchange Management Web Service writes the Full Control right to Exchange over PowerShell.
  7. The EmpowerID Worker Role initiates the Inventory Job for the Active Directory account store in accordance with the inventory schedule.
  8. The LDAP Management Web Service retrieves the permissions associated with the Resource Role Groups and returns them to the EmpowerID Worker Role.
  9. The EmpowerID Worker Role processes those permissions and writes them to the Windows Principal ResourceType Right Table of the EmpowerID Identity Warehouse. The rights written to this table are used by EmpowerID as a baseline for the next iteration of the Enforcement and Projection process.

For EmpowerID to manage native permissions for a resource system in this way, the Rights Enforcement for Resource Role Groups setting for the resource system must be set to allow enforcement, and at least one EmpowerID server must be running the EmpowerID Worker Role Windows service with the Resource Role Reconciliation and Rights Enforcement jobs enabled on that server. Rights Enforcement for Resource Role Groups can be configured in one of the following four ways:

  • No Action — When this option is selected, EmpowerID does not process any form of rights enforcement. Using the image above as an example, this means that if someone grants an EmpowerID Person a Resource Role assignment with the Full Control right, that right has no effect on either EmpowerID or the native Exchange system.
  • Projection with No Enforcement — When this option is selected, changes to rights made within EmpowerID occur only within the EmpowerID Identity Warehouse; they are not passed on to the native environment.
  • Projection with Enforcement (aka "Soft" or "Mixed-Mode") — When this option is selected, changes to rights made within EmpowerID occur within EmpowerID and are enforced within the native environment. In our above example, this option is selected for both the account store and the resource system.
  • Projection with "Strict" Enforcement — When this option is selected, EmpowerID overrides any changes made to rights in the native environment that originate within that system (in contrast with changes originating in EmpowerID). All changes made to rights must occur within EmpowerID to be accepted. Strict enforcement only applies to systems where this mode is implemented (e.g. Active Directory groups).

When Projection with Enforcement or Projection with Strict Enforcement is selected, EmpowerID ensures the native rights granted to your users reflect your security policies. Through a process of continual comparison, the EmpowerID Worker Role measures the rights and membership of any Resource Role Group in your Active Directory with those rights and memberships in the EmpowerID Identity Warehouse. If changes are found, EmpowerID will immediately revert the group back to its previous condition until it can verify that the changes to the group occurred via a change to the delegations of an Access Level assignment. If EmpowerID finds this to be the case, the Worker Role marks the Access Level as "Ready for Projection" and adjusts the group membership accordingly.