...
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 systems' technical or non-human accounts? Do I need a Person object for these?” The answer is not always clear-cut but rather a maybe or sometimes. You are not required to create a Person objects object for non-human 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-human Account.
...
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 systems (e.g. group membership). Group membership can still be managed directly for Accounts without a Person object.
...
AccountStore – represents a directory or user store
ProtectedApplicationResource – represents an application
Account – user or HR record in an external directory/application
Group – group or application role in an external directory/application
GroupAccount – membership of user records in groups in external directories/applications
...