We’ve discussed that EmpowerID inventories and manages resources from resource systems. Another critical set of information EmpowerID retrieves and manages is which accounts and groups have access to these resources in their resource system. For most systems, these accounts and groups reside in the same resource system. For some types of resource systems like Microsoft Exchange, Microsoft SharePoint, Windows File Servers, and others, The accounts and groups do not belong to the same resource system. Using our Active Directory and Exchange example, the mailboxes would exist in a resource system for the Exchange Organization and the Active Directory users and groups 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, Microsoft Exchange supports having mailboxes and granting permissions to 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 domains and the Active Directory Forest concept, EmpowerID has a table named SecurityBoundary. Each Account Store within the Active Directory Forest would belong to a single Security Boundary within EmpowerID representing that forest. Security Boundaries are all of a specific SecurityBoundaryType. Security Boundary Types are where EmpowerID maintains the information pointing to the definition of the connector used for Create, Update, 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 account stores, there will always be at least one resource system, account store, security boundary, and security boundary type.
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.
Related Docs Topics: