...
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 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.
In addition to the relationship where a Person owns an Account, EmpowerID also allows managing which Person is responsible for a technical account or other resource object. This person designated in this relationship with a resource is known as the responsible person. Illustrated below, we can see these various types of Account relationships in practicesupports 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.
...