Person Versus Account

Each IT system or application has the concept of a user or “user account” object. The user account is what is used to control permissions within the application and for authentication. In EmpowerID, the user account object is known as the Person and is stored in the Person table. Anyone authenticating to use the EmpowerID application must have a Person object. All activities are centered around this Person object. For example: assigning roles, granting access, recertifying access, assessing risk, and reporting. Employees, partners, and customers can authenticate and use the EmpowerID applications with only a Person object even if they do not have any other user accounts.

As an Identity Management platform, one of EmpowerID’s primary use cases is to present an accurate picture of the security within each IT system in an organization's on-premise and Cloud landscape. In order to do this, EmpowerID periodically inventories and pulls in the user account objects from these “external” or “managed” systems into the Account table. From here on out we'll refer to them simply as Accounts in order to avoid confusion and avoid the terms user accounts or user. Accounts are users from external systems and Person objects are the primary identity or user object for the EmpowerID system. External systems containing user accounts are known as “Account Stores” in EmpowerID terminology and will be referred to as such going forward.

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 if 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 do they perform in the organization, and other related information considered the business context of the person. In order 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. It is for this purpose and for the management of their lifecycle (creation, modification, deletion) that 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.”

Source: Bago (Editor) E. & Glazer I., (2021) “Introduction to Identity - Part 1: Admin-time (v2)”, IDPro Body of Knowledge 1(5).

A valid question is whether you need to create Person objects for these types of Accounts. The answer is not always clear-cut but rather a maybe or sometimes. You are not required to create a Person object for non-person accounts you wish you manage directly in EmpowerID (create, edit add/remove from groups, reset the password, disable, etc.)

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 login to use any of the 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, this 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. 1) EmpowerID flows attributes between all Accounts owned by the Person and the rules are per Account Store and not per attribute. This would mean that the title, email, and other attributes would be made the same. 2) All access assignments by policy in EmpowerID are summed up on a Person by Person basis and are not account-specific. This means that when a Person is granted membership in a group directly or by one of their roles, that all of the user accounts they own in that Account Store would be added to the group.

In order to segregate the access for a Person’s multiple accounts in the same account store, EmpowerID supports the concept of a core identity. Just as a person can have multiple user accounts in different external directories, so a core identity can have more than one person where the core identity represents the central identity. Core Identity can be seen as master identity which represents one individual who might have one more than professional identity (in EmpowerID represented as person).  Similar to the joining of accounts to people, the joining of person objects to the corresponding core identity will be determined by join rule configuration specific to core identity processing.

Core Identity is used to link all those different professional identities (persons). This data is used to show associated identities on the View One Person page and select the identity to login with during the login to the EmpowerID UI. It also provides a foundation for a fully automated leaver process and deprovisioning of additional identities if the primary person gets terminated. Core Identity stores only basic persons attributes such as first name, last name, birth date, social security number, etc. which are not tied with a job or place in the organization.

Any access assignments, ownership assignments, organizational and job-specific attributes (e.g., department, line manager) can be set on the person only. During the login process, 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. Responsible parties are assigned to signify who is responsible for an IT object from a security and audit perspective.

Any EmpowerID RBAC Actor Type can be assigned as the responsible party, but most organizations configure EmpowerID to only allow the assignment of a Person. The field that stores this assignment is called OwnerAssigneeID, and you can find it in each supported object's table.

When a person is leaving or changing positions, you can transfer all their responsibilities to another party. You can either do this manually, using the Transfer Responsibilities workflow, or automate the process in a Planned Leaver Event.

To help you avoid situations where you have objects with no responsible party, you can run reports to find them.

https://youtu.be/1hp3ru6LnBs