Account Stores and Security Boundaries

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 all belong to 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.

Connectors (OOB)

https://dotnetworkflow.jira.com/wiki/spaces/EAGV22/pages/2809047597

https://dotnetworkflow.jira.com/wiki/spaces/EAGV22/pages/2809047654