Page Comparison

One of the key concepts to understanding EmpowerID is its Identity Warehouse, sometimes known EmpowerID's core functionality relies on a central repository known as the Identity Warehouse, alternatively referred to as the Identity and Entitlement Warehouse. This is the primary database of EmpowerID that stores all major centralized database houses essential data, including configuration :

• Configuration settings and policies

• Core EmpowerID objects

• such as Person and Roles

High-Level Stats for the Identity Warehouse:

• >1,200 tables

• >700 views

• >20,000 stored procedures

• Queues for inbound and outbound changes (Inbox and Outbox)

• Data tables for inventoried objects sourced from external systems

In EmpowerID terminology, these external systems are labeled as "Account Stores" and "Resource Systems."

Identity Warehouse Metrics

• Tables: Approximately 1,200

• Views: Over 700

• Stored Procedures: Around 20,000

Understanding the specifics of these tables, views, and stored procedures as is not required since most are used designated for internal purposesfunctionality. Key views and stored procedures used by the elements relevant to 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 the Identity Warehouse 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 workflows and code act to create, update, or delete them. All of the columns in SQL for a table or view become properties of its corresponding programmable component object. Therefore, extending the schema is referred to as extending the components by adding new “virtual” properties or methods. We’ll talk about extending the schema in more depth in a later training module.

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

Insert excerptIL:External StylesheetIL:External Stylesheetnopaneltrue Info

Key Takeaways:

EmpowerID Components and API Integration

EmpowerID Components serve as programmable objects that expose the Identity Warehouse’s underlying structure for API usage. These components enable:

1. Data retrieval for user interfaces

2. Create, update, or delete operations via workflows or custom code

Each SQL table or view column translates into a property of the corresponding component. Schema extensions involve the addition of new virtual properties or methods to these component objects.

RBAC Objects

Within the schema management user interface, these components are tagged as "RBAC Objects." An entry corresponding to each SQL table or view exists in the RBACObject table for display. Their associated SQL stored procedures can be inspected under the "RBAC Object Methods" tab.

API Accessibility

• The Account component, corresponding to the SQL account table, is not exposed via the API.

• The AccountView component, with enhanced security features, is available through the API.

Key Takeaways

1. EmpowerID relies on a central repository known as the Identity and Entitlement Warehouse.

2. This warehouse functions as a relational database that stores configurations, core EmpowerID objects, and inventoried data from external systems.

3. Programmable objects, referred to as components, expose the Identity Warehouse's underlying SQL tables and views for API interaction.

4. Views in EmpowerID generally feature built-in security and data filtering

1. , making them the preferred choice for user interface exposure.

2. Components are also

1. tagged as RBAC Objects, and their API accessibility can be

1. toggled via a checkbox in the schema management user interface.