EmpowerID Concepts
- Phillip Hanegan
One of the key concepts to understanding EmpowerID is its Identity Warehouse, sometimes known as the Identity and Entitlement Warehouse. The Identity Warehouse is the central database of EmpowerID that stores all primary data, including configuration and policies, significant 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 managed systems external to EmpowerID. EmpowerID refers to these external managed systems as Account Stores and Resource Systems.
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 for internal use. Key views and stored procedures used by the user interfaces can be identified by pressing F12 in your browser and viewing the network tab.
EmpowerID “Components”
When working with EmpowerID or its support staff, a key term you will encounter is “EmpowerID Components.” These components are how EmpowerID exposes the tables, views, and stored procedures of the Identity Warehouse 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 present their data, workflows, and code to allow CRUD operations to be performed. 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 to them 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.
Key Takeaways:
EmpowerID is built on what is called an Identity and Entitlement Warehouse
The Identity and Entitlement Warehouse is a highly relational database storing configuration, EmpowerID IAM objects, and objects inventoried from external managed systems.
Tables and views are made into programmable objects with an API called components.
Views have built-in security and data filtering and are, therefore, what is usually exposed in the user interfaces.
Components are also known as RBAC Objects and can be made accessible or inaccessible via API by checking a checkbox.