Page Comparison

One of the core concepts in EmpowerID is EmpowerID's core functionality relies on a central repository known as the Identity Warehouse, also known alternatively referred to as the Identity and Entitlement Warehouse. This is the central database of EmpowerID that stores all critical 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 tabaccessing the browser's network tab using the F12 key.

EmpowerID Components and API Integration

EmpowerID 's "components" are Components serve as programmable objects that expose the Identity Warehouse's tables, views, and stored procedures for use in the API. The user interface retrieves data from these objects, while workflows and code create, update, or delete them. Each column in the SQL tables and views becomes a property of its corresponding programmable component object, and extending the schema involves adding 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

While the list of components is extensive, many are disabled by default and not visible in the user interfaces or available to custom applications and developers. For example, the Account component, which represents the SQL account table, is not available in the API, but the more secure AccountView component is. These components are labeled Within the schema management user interface, these components are tagged as "RBAC Objects" in the schema management user interface, and an entry for each ." An entry corresponding to each SQL table or view is stored exists in the RBACObject table for display purposes. The Their associated SQL stored procedures for these components can be seen on inspected under the "RBAC Object Methods" tab.

Key Takeaways:

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.