Glossary

Access Levels are bundles of EmpowerID operations and/or native system rights specific to a resource type (such as Exchange mailboxes or user accounts) that, when assigned to users, give those users the ability to access IT resources in the manner specified by the Access Level. Each resource type has its own set of Access Levels defined with different combinations of EmpowerID operations and rights (where applicable) to ensure that the level of access to the resources remains consistent for the type and the assignment.

EmpowerID manages, inventories, and protects resources within what is known as resource systems. Account Stores represent a special type of resource system managed by EmpowerID. What makes account stores different from other resource systems is their function as directories containing user account objects and can perform their own authentication, such as Active Directory.

Approval Flow Policies are essential for automating the approval process in EmpowerID. They manage necessary approval steps when users submit "Business Requests" with resource items, ensuring access is granted only after approval. These policies guide the creation of Approval Flow policies tailored to an organization's needs, directing requests to the requestor's manager for approval. The policies also allow for configuring approval steps, decisions, and item-level actions.

An Approval Flow Step is a sequential stage in the Approval Flow policies that requires approval before progressing. It defines the number of approvals needed for fulfillment and can be configured for "step-level" fulfillment. Each step can have its own approval flow, and can be set for Item Level approval.

Approver Resolver Rules specify to whom an Approval Flow Step needs to route for approval in the event a default approver does not exist. These rules can be routed to various actors in EmpowerID, including the Initiator Manager, Target Person Manager, Resource Owner, RBAC Approver, Static Approver, and Fallback Approver.

A group that represents a specific access assignment in an application or directory system. The group can either be a security group in Active Directory or a generic group in EmpowerID representing a group or role in a target application.

Management Roles represent Authorization Packages (AKA Business Functions) in EmpowerID. An Authorization Package is a business-designed bundle of access required to complete a Business Function or participate in a team or working group. Authorization packages bundle access across multiple systems and present a non-technical assignable access unit. The Management Role allows this flexibility and enables the business owners to create friendly, non-technical descriptions and manage the governance cycle of these packages.

Birthright access is a term used to define a Person’s initial access to IT systems based on their role in the organization. It is the access they automatically receive by policy without generating any requests for access. EmpowerID divides this access into two types: Provisioning Policies, which define the new objects that should be automatically created for a Person, and then access assignments which are the policies that will add the Person’s user accounts to groups, application roles or permissions.

A Business Role is a user-defined hierarchical container for grouping EmpowerID Person objects that can delegate access to resources based on a particular job function.

Business Requests are requests submitted by users for access to resources in the IAM Shop. These requests are directed to managers or delegated individuals for approval, rejection, or delegation. The EmpowerID system allows for streamlined and efficient approval processes, providing details about the request and enabling actions such as approval, rejection, or delegation.

The BusinessRequestFlowEventInbox is a table used to record events triggered by the Mover Detection Engine. It stores entries related to the Mover's event, including details such as TimeGenerated, Table_Name, PersonID, Department, Previous_Department, and more. The table is utilized to track and manage the Mover events and subsequently trigger workflows and notifications as required.

Business Request Expiration refers to the time limit for a Business Request to be fulfilled or expired. It is crucial for managing user access within an organization, ensuring timely decisions on access requests. The expiration period is typically defined based on the organization's policies and compliance requirements. Once a Business Request expires, it may need to be reinitiated or reviewed to maintain effective access management.

The Business Request JSON Inbox Processor is a job in EmpowerID responsible for identifying expired business requests and updating their status to "Expired." This ensures that these requests no longer appear for approval, preventing further actions on invalid requests. The processor checks for specific conditions, including the request's status and expiration dates, to determine if a request is expired.

People belong to companies via their Business Role and Location assignments.

Compliant access delivery refers to providing secure and controlled access to information or resources per relevant laws, regulations, and policies. This type of access ensures that sensitive information is protected and that access to it is granted only to authorized individuals with a legitimate need for it. The goal of compliant access delivery is to balance the need for information access with the need to protect against security risks, such as unauthorized access, theft, or misuse of information.

Single entity per human or IoT. A core identity can be the owner of multiple person objects.

Objects representing collections of people to which policies can be assigned. These include Person, Group, Management Role Definition, Management Role, Query-Based Collection, Business Role and Location.

Accounts – Accounts are users inventoried from external systems and may or may not have a single person assigned as the owner. Accounts such as service identities can be managed but do not always require a Person object for management. Often a person object will be created anyway to leverage the ease of assigning RBAC policies for group membership and other access. Accounts in social media systems or web applications are linked to a person to facilitate single sign-on between systems.

Person – A Person is an object in EmpowerID that represents a human being. A Person typically owns multiple user accounts in external systems such as Active Directory, Azure AD, Facebook, SAP, etc. 

Business Role and Location – In EmpowerID, a Business Role is a user-defined hierarchical container for a grouping of EmpowerID Person objects that can be used for delegating access to resources based on a particular job function; in its simplest form, an EmpowerID Location is a container for holding resources. These two objects combine in EmpowerID to determine a collection of people based on job function and location within an organization.

Group – Groups are collections of users that can be used as vehicles to grant access to user accounts belonging to them.

Management Role – Management Roles are user-defined containers holding collections of Access Levels that have been packaged into responsibility or job-based bundles to allow for the quick and easy bulk assignment of access to resources across multiple systems. They are like groups in EmpowerID that are not limited to granting access to only the resources in a single system. Management Roles have a single-level hierarchy, inheriting access from their Management Role Definition.

Query-Based Collections – Query-based Collections, also known as Set Groups, are logical bundles of Sets (queries made against the EmpowerID Identity Warehouse that result in collections of people or resources) grouped together with a friendly name for resource management. Set Groups offer advantages over groups and roles in that they can contain any resources, are continuously evaluated to ensure they contain the appropriate resources and can be used as actors and recipients of EmpowerID policies for provisioning, deprovisioning, attribute assignment, password policies, etc.

EmpowerID functionality is broken down into many granular "jobs," which are hosted and run in Windows services that communicate back to the EmpowerID Identity Warehouse over REST Web services. Jobs are either specific tasks that run on a scheduled basis (such as Inventory) or REST Web Services used in workflow processes.

An EmpowerID Location is a container for holding resources.

Notification Policies refer to the configuration of the quantity and variety of notifications sent by EmpowerID to Business Request participants. These policies can be managed at the organizational level, allowing the enablement or disablement of specific notifications. Additionally, users can be granted the ability to configure their own preferences for a more personalized experience.

Each EmpowerID Operation is a protected code object that, when executed within an EmpowerID workflow, allows a resource within EmpowerID or a custom application to be accessed in a way consistent with the operation and the type of resource being accessed. Some examples include adding users to groups, creating mailboxes, updating user attributes, and viewing certain objects such as EmpowerID pages and reports.

An OrgRole is an object in EmpowerID that represents a person's Business Role. Business Roles are always assigned to people in conjunction with an Organizational Location.

An OrgZone is an Organizational Location / Business Context that is always assigned in conjunction with a Business Role. For resources that are not Person objects, Locations are used to organize them into hierarchies for managing inherited access policies.

A Person is an object in EmpowerID that represents a human being. A Person typically owns multiple user accounts in external systems such as Active Directory, Azure AD, Facebook, SAP, etc. The EmpowerID Person is the base identity in the EmpowerID RBAC model, without which a user cannot access any resources or perform any tasks.

A person's core identity can be linked to multiple sub-person objects: professional identities (i.e., have the business information attached).

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

Resources are the lowest level secured base objects in EmpowerID for which management tasks can be performed. All objects of any type securely managed by EmpowerID have a resource entry in the EmpowerID Identity Warehouse.

Resource systems define the specific system within which a resource resides. They can include Active Directory domains, LDAP directories, HR systems, Microsoft Exchange Organizations, SharePoint Farms, custom applications, and the EmpowerID system.

Risk management is the process of managing risks associated with an organization’s IT resources. It involves identifying, assessing, and treating risks to those resources in a manner that best reflects the organization’s risk tolerance. EmpowerID Risk management has the following components:

Global Function

Business-specific activity, usually in Verb Noun, e.g., Create Purchase Order. Defines the business activity, risk level, and mitigating controls.

Local Function

The local version of a function used in risk policies. Localized means that it can specify the “where” for the function, e.g., Create Purchase Orders in the Widgets sub-company.

Global Risk

Policies that define functions that are critical/sensitive or those where two combinations of functions produce a toxic combination or SOD violation.

Local Risk

The local version of a global risk. Local risks are scoped to a specific instance of an application

Risk Owner

Risk owners are business users responsible for risks and have the ability to approve, mitigate, or remediate violations.

Rules

Rules are the functions added to local risk policies.

Mitigating Controls

Checks and balances are assigned to global risks that can be linked to violations if the risk owner decides that the violation should be allowed (mitigated). For example, “Bob” checks the record of purchase orders monthly to mitigate the risk that he might engage in unethical behavior.

Violation

A violation occurs when the rules that comprise a local risk are broken. Violations only occur for local risks. EmpowerID distills all violations down to the person violating the rule, regardless of how they received the violating functions. For example, if numerous people belong to a role that has the function, EmpowerID flags each person in the role as a violator to give you a full picture of the magnitude of the risk. Risk owners can view the exact assignment point that caused the person to be in violation.