Skip to end of banner
Go to start of banner

Person Versus Account

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

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. Accounts are users from external systems and Person objects are the primary identity or user object for the EmpowerID system.

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.

Compliant Access Delivery synthesizes multiple Identity and Access Management (IAM) technologies with a business modeling approach to automate and maintain each user with their appropriate Access to IT systems while continuously minimizing risk.

  • Core Identity – single entity per human or IoT​

  • Person — core identity can be the owner of other person objects ​

  • OrgRoIe — Business Role always assigned in conjunction with an Organizational Location ​

  • OrgZone — Organizational Location / Business Context always assigned in conjunction with a Business Role ​

  • Polyarchical RBAC — Business Roles and Locations are both hierarchical trees. People are assigned to one or more Business Roles each for a specific Location/Context. This polyarchy dramatically reduces the number of roles and eliminates role bloat ​

  • Company — people belong to companies via their Business Role and Location assignments ​

  • Personas — person core identity can be linked to multiple sub-person objects which are the ​professional identities — i.e. have the business ​information attached​

  • 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​

Deciding When You Need a Person Object
  • If the account is the HR record for a human being

  • If the user will login to use any of the EmpowerID applications or user interfaces

  • If the account requires access to perform self-service password reset

  • If you would like to shop for access in the IT Shop for the Account

  • If you would like to assign EmpowerID roles to the account so it receives policy-controlled access

  • If the account will be used to authenticate to the EmpowerID API

  • No labels