...
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 each of 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. In order 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.
| Info |
|---|
Key Concept: Account Store Identity Entry The Account Store Identity Entry (ASIE), is the actual live representation of an object in an external system being 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. |
...