Page Comparison

One of the key core concepts to understanding in EmpowerID is its the Identity Warehouse, sometimes also known as the Identity and Entitlement Warehouse. This is the primary central database of EmpowerID that stores all major critical data, including configuration and policies, major EmpowerID objects like Person and Roles, inbox and outbox queues used to stage detected changes and outbound changes between EmpowerID and managed systems, as well as the tables holding the inventoried objects and their data from external managed systems. External managed systems are referred to as Account Stores and Resource Systems in EmpowerID terminology.

High-Level Stats for the Identity Warehouse:

• >1,200 tables

• >700 views

• >20,000 stored procedures

It is not essential to learn the specifics of these tables, views, and stored procedures as most are used for internal purposes. Key views and stored procedures used by the user interfaces can be identified by hitting F12 in your browser and seeing which is being called on the network tab.

EmpowerID

Components

When working with EmpowerID or its support staff, a key term you will encounter is the EmpowerID “Components.” The components are how EmpowerID's "components" are programmable objects that expose the Identity Warehouse's tables, views, and stored procedures are exposed for use in the API. All major SQL tables and views are created as programmable objects against which the user interface acts to retrieve and view their data and The user interface retrieves data from these objects, while workflows and code act to create, update, or delete them. All of the columns in SQL for a table or view become properties Each column in the SQL tables and views becomes a property of its corresponding programmable component object. Therefore, and extending the schema is referred to as extending the components by involves adding new “virtual” virtual properties or methods . We’ll talk about extending the schema in more depth in a later training module. Although to these objects.

While the list of components is extensive, many are disabled by default and not available to show visible in the user interfaces or be called by available to custom applications and developers. As a quick illustration, we can see that For example, the Account component, which represents the SQL account table, is not available in the API, while but the more secure AccountView component is. To be noted, These components are labeled as "RBAC Objects" in the schema management user interface labels components as RBAC Objects. This is because there is , and an entry for every each table and view, aka “component” or view is stored in the RBACObject table , used to display this datafor display purposes. The SQL stored procedures for these components can be seen on the RBAC Object Methods tab.