Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

We’ve previously discussed that EmpowerID inventories and manages is capable of managing and inventorying resources from resource systems. Another critical set of information EmpowerID retrieves and essential aspect that EmpowerID manages is which the accounts and groups that have access to these resources in within their resource system. For In most systemscases, these accounts and groups reside in exist within the same resource system . For some types of as the resources they access. However, for some resource systems like Microsoft Exchange, Microsoft SharePoint, Windows File Servers, and others, The the accounts and groups do not belong to the same resource system . Using our as the resources.

To understand this relationship, EmpowerID maintains a record in the AccountStore table for directories containing account and group objects. This record denotes that these resource systems contain security principals that can access resources in other resource systems. For example, in the case of Active Directory and Exchange example, the mailboxes would exist in a resource system for the Exchange Organization, and the Active Directory users and groups exist in a resource system specific to their AD domain. For EmpowerID to understand this relationship, the resource systems for directories containing account and group objects also have a record in the AccountStore table. This denotes that these resource systems contain security principals that can access resources in other resource systems. To further complicate the security picture

Additionally, Microsoft Exchange supports having mailboxes and granting permissions to allows mailboxes to be associated with and accessed by accounts and groups from multiple Active Directory domains within a single forest. This means that we would have multiple different resource systems and Account Stores for these Active Directory Domains and another resource system for the Exchange Organization. Based on the trust relationship between these Active Directory domains, EmpowerID must understand which accounts and groups could be granted permissions for which mailboxes and which could not. To represent this trust relationship between can create a complex security picture with multiple resource systems, account stores, and security boundaries that EmpowerID needs to understand in order to accurately manage entitlements. To represent the trust relationships between these domains and the Active Directory Forest conceptforest, EmpowerID has a table named called SecurityBoundary. Each Account Store within in the Active Directory Forest would belong forest belongs to a single Security Boundary within in EmpowerID representing that represents the forest. These Security Boundaries all belong to are part of a specific SecurityBoundaryType. Security Boundary Types are where EmpowerID maintains the information pointing to the definition of the , which defines the connector used for Createcreating, Updateupdating, Delete, and the attribute schema of the native objects directly managed in an external system. So in the case of our resources contained in resource systems that are and deleting objects in the external system and their attribute schema. Therefore, for resources contained in account stores, there will always be at least one resource system, account store, security boundary, and security boundary type in EmpowerID.

Info

Account Store Identity Entry

The Account Store Identity Entry (ASIE) is the actual live representation of an object in an external system modified by EmpowerID. The ASIE is the implementation of the CRUD methods and the attributes that are specific to that Security Boundary Type and object type in that system.

Key Concept: EmpowerID workflows and API calls operate against Components, not AccountStoreIdentityEntry. This means that the same workflows will work for objects in any system. Any new connected system can use the existing workflows.

...