Person Versus Account

In every IT system or application, the concept of a user or "user account" object is fundamental. This user account is central to managing permissions and handling authentication within the system. In EmpowerID, the equivalent of the user account object is called the "Person," which is stored in the Person table. Any individual who authenticates to use the EmpowerID application must have a Person object, as all activities within the system revolve around this object. For example, assigning roles, granting access, recertifying access, assessing risk, and reporting are all processes linked to the Person object. Employees, partners, and customers can authenticate and use EmpowerID applications solely with a Person object, even if they do not have any other associated user accounts.

As an identity management platform, one of EmpowerID's primary use cases is to accurately represent security within each IT system in an organization's on-premises and cloud environments. EmpowerID periodically inventories and imports user account objects from these external or managed systems into its Account table. To avoid confusion, these imported user accounts will be referred to as "Accounts," while "Person" will refer to the primary identity or user object within EmpowerID. External systems that contain these Accounts are referred to as "Account Stores" in EmpowerID terminology.

A key use case for EmpowerID is to present an accurate picture of the access assigned to Accounts across an organization’s IT systems and to ensure that this access complies with risk policies. But what makes access “compliant”? Compliant access is appropriate to the person to whom it is assigned and adheres to organizational standards and business policies designed to minimize risk. The appropriateness of access in IT systems is based on who the person is, their role in the organization, and other related information that forms part of the person's business context. To achieve a holistic view and analysis, a Person’s Accounts must be linked together and managed as a whole, not in isolation. These Accounts are thus linked and owned by a single Person object to facilitate their lifecycle management, including creation, modification, and deletion.

Open

Entity Relationships for Person and Account

Open

Account Types and Relationships to Person

Account Types and Relationships to Person

What About Accounts That Aren’t People?

A common question arises: “What about non-human or technical accounts from downstream Account Stores?” Often used for devices, services, and servers, these accounts are called "Non-Person Accounts." Unlike HR accounts, which represent human users, Non-Person Accounts do not necessarily require a corresponding Person object in EmpowerID. Whether you need to create a Person object for these Accounts depends on specific use cases. For instance, you might create a Person object for a Non-Person Account if:

• The Account will log in to use any EmpowerID applications, user interfaces, or REST APIs (e.g., for PAM Application to Application, Bots, etc.).

• You need to manage access to the account via the IT Shop.

• The owner of the technical account requires self-service password reset capabilities.

• You want to assign EmpowerID roles to the Account so that it receives policy-controlled access in downstream Account Stores (e.g., group membership).

• You wish to manage attribute synchronization between the Account and other related Accounts.

Group membership can still be managed directly for Accounts without a Person object, but certain scenarios may require linking to a Person object.

Handling Multiple Person Objects for the Same Person

Sometimes, a single individual may require multiple Person objects within EmpowerID. This typically occurs when a person has privileged access within an account store, which might involve creating an additional privileged account for admin activities. For example, a person might have two accounts within the same domain in Active Directory. However, linking these two account objects to the same person in EmpowerID can lead to unintended consequences:

• EmpowerID flows attributes between all Accounts owned by the Person, applying rules on a per-account store basis, not per attribute, which could result in the same title, email, and other attributes across all Accounts.

• All access assignments in EmpowerID are calculated on a person basis and are not account-specific. Thus, when a person is granted group membership or role-based access, all user accounts they own within that Account Store are added to the group.

To prevent these issues, EmpowerID supports the concept of a core identity. This core identity represents the central identity of an individual and can be linked to multiple Person objects, each representing a different professional identity. The core identity facilitates the management of these multiple identities, including automated processes such as deprovisioning additional identities when the primary person is terminated. Core Identity stores basic personal attributes (e.g., first name, last name, birth date) not tied to specific job roles or organizational positions. Access assignments, ownership assignments, and job-specific attributes remain tied to individual Person objects.

Managing Resource Responsibility

In addition to the relationship where a Person owns an Account, EmpowerID allows the assignment and tracking of responsible parties for key objects like accounts, groups, computers, management roles, locations, and shared credentials. This relationship of responsibility differs from account ownership, which signifies a personal account for the individual. The responsible party is the designated individual or entity accountable for the security and management of an IT object.

EmpowerID allows any RBAC Actor Type to be assigned as a responsible party, although most organizations restrict this to Person assignments. This assignment is stored in the OwnerAssigneeID field within each supported object's table.

When a person leaves the organization or changes roles, their responsibilities can be transferred to another party manually through the Transfer Responsibilities workflow or automatically as part of a Planned Leaver Event. To avoid having objects without an assigned responsible party, EmpowerID provides reports that can identify such cases.