Understanding the Relationship Between Persons and Accounts
- Phillip Hanegan
In every IT system or application, the concept of a "user" or "user account" is fundamental. These objects are central to managing permissions and handling authentication. In EmpowerID, the equivalent of a user account is the Person, stored in the Person table. Any individual who authenticates using EmpowerID must have a Person object, as this serves as the foundation for all system activities. From assigning roles and granting access to recertifying permissions, assessing risk, and reporting, everything in EmpowerID revolves around the Person object. Employees, partners, and customers can authenticate and interact with EmpowerID applications using only a Person object, even without additional user accounts from external systems.
Persons and Accounts in EmpowerID
EmpowerID distinguishes between two primary types of identity objects: Persons and Accounts.
Persons represent the primary identity within EmpowerID, encapsulating all user-related activities and access management.
Accounts are user objects imported from external systems (referred to as "Account Stores"), such as Active Directory or cloud-based applications. These accounts are stored in the EmpowerID Account table.
EmpowerID periodically inventories and imports user accounts from external systems to provide a unified view of organizational access. This clear distinction allows EmpowerID to maintain a consistent identity model while managing security and access across diverse systems.
Linking Accounts to Persons for Unified Identity Management
A core function of EmpowerID is linking Accounts from various Account Stores to the corresponding Person object. This linkage ensures a holistic view of an individual’s access across all systems. Managing Accounts as part of a Person’s identity allows for seamless lifecycle management, including:
Creation: Automatically provisioning Accounts and their links to a Person object.
Modification: Updating access and attributes based on role or organizational changes.
Deletion: Ensuring proper deprovisioning of all linked Accounts when a Person leaves the organization.
This unified management approach ensures that access complies with organizational risk policies, aligning with the principle of “compliant access,” which requires that access assignments are appropriate to the person’s role and business context.
Non-Person Accounts: Managing Technical Identities
Not all Accounts represent human users. Many external systems include Non-Person Accounts, such as those for devices, services, or applications. In EmpowerID, Non-Person Accounts do not always require a corresponding Person object. However, there are specific scenarios where linking a Non-Person Account to a Person object is beneficial, such as:
Enabling login access to EmpowerID applications, user interfaces, or APIs (e.g., for bots or application-to-application authentication).
Managing access through the IT Shop.
Allowing the account owner to use self-service password reset capabilities.
Assigning EmpowerID roles to control policy-driven access to downstream systems.
Synchronizing attributes between the Account and other related objects.
Non-Person Accounts can still be managed independently without a linked Person object for scenarios where these requirements do not apply.
Managing Multiple Person Objects for the Same Individual
There are cases where a single individual may require multiple Person objects. This commonly occurs when a person has both standard and privileged access within the same system, such as separate user and administrative accounts in Active Directory. While EmpowerID supports linking multiple Accounts to a single Person, doing so can create challenges.
Challenges with Multiple Linked Accounts
Attribute Flow: EmpowerID synchronizes attributes across all linked Accounts owned by a Person, which can lead to unintended attribute updates (e.g., email or title) across all Accounts.
Access Calculation: Access assignments are applied at the Person level, not account-specific, meaning all Accounts owned by a Person inherit the same group memberships and role-based access.
The Role of Core Identity
To address these complexities, EmpowerID introduces the concept of a Core Identity. A Core Identity represents the central identity of an individual and can be linked to multiple Person objects, each representing distinct professional roles or privileges. This approach ensures:
Separation of access and attributes tied to specific roles or accounts.
Automated deprovisioning of additional identities when the primary Person object is terminated.
Simplified management of core attributes, such as name and birth date, that are not tied to a specific job role.
Assigning Resource Responsibility in EmpowerID
In addition to owning Accounts, Persons in EmpowerID can be assigned as responsible parties for key resources, including accounts, groups, computers, management roles, locations, and shared credentials. This resource responsibility relationship is distinct from account ownership and signifies accountability for managing the security and lifecycle of IT objects.
Assigning and Managing Responsibilities
EmpowerID supports assigning responsibility to any RBAC actor type, though most organizations restrict this to Persons. These assignments are tracked using the OwnerAssigneeID field in the relevant object tables.
Transferring Responsibilities
When a person leaves the organization or transitions to a new role, their responsibilities can be transferred to another individual either manually using the Transfer Responsibilities workflow or automatically during a Planned Leaver Event. EmpowerID also provides reports identifying resources without an assigned responsible party, ensuring no object is left unmanaged.
Watch the video below for more information about Persons and accounts in EmpowerID