...
We mentioned above that a key use case is to present an accurate picture of the access assigned to Accounts across an organization’s IT systems and whether it is compliant with risk policies. What makes access “compliant”? Compliant access is appropriate to the person to whom it is assigned in compliance with the organizational standards and business policies to minimize risk. The key here is that the appropriateness of access in IT systems is based on who they are, what role they perform in the organization, and other related information considered within the business context of the person. To have a holistic view and analysis of this information, a Person’s Accounts cannot be analyzed and managed In isolation but must be linked together and viewed as a whole unit. For this purpose and the management of their lifecycle (creation, modification, deletion), they are linked and owned by a single Person object.
What About Accounts That Aren’t People?
The first thing many of you might ask yourself is, “Yes, HR Accounts are always human people, but what about the downstream Account Stores' technical or non-human accounts? These accounts are referred to as “Non-Person Accounts” and defined as “Any account not specifically assigned to a person, such as accounts used for devices, services, and servers.”
...
Below is a list of common use cases for which you would want to create a Person object to own the non-person Account.
Deciding When You Need a Person Object
If the Account will log in to use any EmpowerID applications, user interfaces, or REST APIs (e.g., PAM Application to Application, Bots, etc.)
If you would like to shop for access in the IT Shop for the Account
If the owner of the technical Account requires access to perform a self-service password reset for the password of the technical Account
If you would like to assign EmpowerID roles to the account so it receives policy-controlled access in downstream Account Stores (e.g., group membership). Group membership can still be managed directly for Accounts without a Person object.
If you would like attribute changes to flow between that Account and other related Accounts.
Handling Multiple Person Objects for the Same Person
Some situations require multiple Person objects for the same human being or non-human identity. A typical case is where a Person has privileged access in an Account Store. Privileged access is often granted by creating an additional personal privileged Account in the Account Store for use by that person when performing admin activities. Using Active Directory as an example would mean that a Person would have two Accounts in the same AD domain (Account Store). If EmpowerID were to link these two Account objects to the same person, some undesired consequences would occur:
...
Access assignments, ownership assignments, organizational and job-specific attributes (e.g., department, line manager, etc.) can be set on the person only. Users can use only the person’s credential to log in as core identity does not have its own credentials.
Managing Resource Responsibility
In addition to the relationship where a Person owns an Account, EmpowerID supports assigning and tracking responsible parties for key objects like accounts, groups, computers, management roles, locations, and shared credentials. This responsibility relationship differs from that of a Person owning an account. An account owned by a Person represents that person and serves as their personal account. From a security and audit perspective, responsible parties are assigned to signify who is responsible for an IT object.
...