Groups and Membership

The most important type of entitlement managed by EmpowerID is group membership. Applications and directories use groups or collections of users by any other name (application roles, profiles, etc.) as the primary mechanism to grant permissions to accounts. EmpowerID has provided deep group management and self-service capabilities since its first release. One key design decision was to normalize any collection of users in an external Account Store into the same set of tables and components for groups and their members. EmpowerID does not segregate groups for various system types or types of groups into different tables and components. This allows EmpowerID to provide a single set of functionality for all currently connected system types and any future system types. All user interfaces, workflows, and APIs work for all systems' groups.

EmpowerID inventories all groups from connected Account Stores into the Group table on a 10-minute interval by default. New groups are detected and as well as any deleted groups. Inventory also retrieves the membership of each group and stores this information in the GroupAccount table. Any membership changes discovered are also logged in the GroupAccountHistory table for reporting purposes. For systems supporting the nesting of groups, EmpowerID stores this information on the GroupMemberGroup table.

Some systems, such as Microsoft Azure AD and Teams, support the assignment of Accounts as Owners of the group within the Account Store. EmpowerID inventories this information and records changes in the GroupOwnerAccount and GroupOwnerAccountHistory tables, respectively.

Open

Data Model for Groups and Related Components

In addition to reporting on this information and tracking changes, EmpowerID includes a full set of workflows allowing delegated admins and end-users to manage members, owners, and request access. These are a single set of workflows and user interfaces that work for all Account Store connectors that have implemented group membership functionality. As mentioned previously, the workflows operate against the Group and GroupAccount component API objects, and live changes are made based on the connector implementation of the Account Store Identity entry for that Security Boundary Type. The same connector code is called live from interactive workflows and in background processes and jobs that enforce calculated policy-based access.

Group Administration