Each In every IT system or application has , the concept of a user or “user account” object. The "user account" object is fundamental. This user account is what is used central to control managing permissions and handling authentication within the application and for authenticationsystem. In EmpowerID, the equivalent of the user account object is called the "Person and ," which is stored in the Person table. Anyone authenticating Any individual who authenticates to use the EmpowerID application must have a Person object. All activities are centered , as all activities within the system revolve around this Person 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 the EmpowerID applications solely with only a Person object, even if they do not have any other associated user accounts.
As an Identity Management identity management platform, one of EmpowerID’s EmpowerID's primary use cases is to present an accurate picture of the accurately represent security within each IT system in an organization's on-premise premises and Cloud landscape. To do this, cloud environments. EmpowerID periodically inventories and pulls in the imports user account objects from these “external” external or “managed” managed systems into the its Account table. From this point forward, we'll refer to them simply as Accounts to avoid confusion and avoid the terms user accounts or user. Accounts are users from external systems, and Person objects are To avoid confusion, these imported user accounts will be referred to as "Accounts," while "Person" will refer to the primary identity or user object for the within 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 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 whether it is compliant to ensure that this access complies with risk policies. What But what makes access “compliant”? Compliant access is appropriate to the person to whom it is assigned in compliance with the and adheres to organizational standards and business policies designed 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 the person is, their role in the organization, and other related information considered within the that forms part of the person's business context of the person. To have achieve 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 managed as a whole unit. For this purpose and the management of their lifecycle (creation, modification, deletion), they are , 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.
Account Types and Relationships to Person
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 A common question arises: “What about non-human or technical accounts ? These accounts are referred to as “Non-Person Accounts” and defined as “Any account not specifically assigned to a person, such as accounts from downstream Account Stores?” Often 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, 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.)If you would like to shop for access in .
You need to manage access to the account via the IT Shop for the AccountIf the .
The owner of the technical Account account requires access to perform a self-service password reset for the password of the technical AccountIf you would like capabilities.
You want to assign EmpowerID roles to the account 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
.If you would like attribute changes to flow between that Account and other related Accounts, but certain scenarios may require linking to a Person object.
Handling Multiple Person Objects for the Same Person
Some situations Sometimes, a single individual may require multiple Person objects for the same human being or non-human identity. A typical case is where a Person within EmpowerID. This typically occurs when a person has privileged access in an Account Store. Privileged access is often granted by within an account store, which might involve creating an additional personal privileged Account in the Account Store for use by that person when performing account for 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 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 , some undesired consequences would occurin 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 segregate the access for a Person’s multiple accounts in the same account storeprevent these issues, EmpowerID supports the concept of a core identity. Just as a person can have multiple user accounts in different external directories, a core identity can have more than one person where the core identity This core identity represents the central identity . Core Identity can be seen as a master identity representing one individual who might have one or more professional identity (represented in EmpowerID as a person). Like the joining of accounts to people, the joining of person objects to the corresponding core identity is 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 selecting the identity to log in 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 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 only basic persons attributes such as personal attributes (e.g., first name, last name, birth date, social security number, etc., which are ) not tied with a to specific job or place in the organization.roles or organizational positions. 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 credentialsremain tied to individual Person objects.
Managing Resource Responsibility
In addition to the relationship where a Person owns an Account, EmpowerID supports assigning 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 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 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.
Any EmpowerID allows any RBAC Actor Type can to be assigned as the a responsible party, but although most organizations configure EmpowerID only restrict this to allow Person assignments. The field that stores this This assignment is stored in the OwnerAssigneeID field , and you can find it in within each supported object's table.
When a person is leaving or changing positions, you can transfer all their responsibilities leaves the organization or changes roles, their responsibilities can be transferred to another party . You can either do this manually, using manually through the Transfer Responsibilities workflow or automate the process in automatically as part of a Planned Leaver Event. To help you avoid situations where you have objects with no avoid having objects without an assigned responsible party, you can run reports to find themEmpowerID provides reports that can identify such cases.
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
| Info |
|---|
Key Takeaways:
|