One of the key concepts to understanding EmpowerID is its Identity Warehouse sometimes known as the Identity and Entitlement Warehouse. This is the primary database of EmpowerID that stores all major 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.
High-Level Stats for the Identity Warehouse:
>1,200 tables
>700 views
>20,000 stored procedures
It is not important to learn the specifics of these tables, views, and stored procedures as the majority are used for internal purposes. Key views and stored procedures and used by the user interfaces and can be identified by hitting F12 in your browser and seeing which is being called on the network tab.
EmpowerID “Components”
A key term you will encounter when working with EmpowerID or its support staff are the EmpowerID “Components”. The components are the way in which 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. Extending the schema is therefore 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 very large, many are disabled by default and not available to show in the user interfaces or to 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 their is an entry for every table and view, aka “component” in the RBACObject table which is used to display this data. The SQL stored procedures for these components can be seen on the RBAC Object Methods tab.
Core Identity – single entity per human or IoT
Person — core identity can be the owner of other person objects
OrgRoIe — Business Role always assigned in conjunction with an Organizational Location
OrgZone — Organizational Location / Business Context always assigned in conjunction with a Business Role
Polyarchical RBAC — Business Roles and Locations are both hierarchical trees. People are assigned to one or more Business Roles each for a specific Location/Context. This polyarchy dramatically reduces the number of roles and eliminates role bloat
Company — people belong to companies via their Business Role and Location assignments
Personas — person core identity can be linked to multiple sub-person objects which are the professional identities — i.e. have the business information attached
AccountStore – represents a directory or user store
ProtectedApplicationResource – represents an application
Account – user or HR record in an external directory/application
Group – group or application role in an external directory/application
GroupAccount – membership of user records in groups in external directories/applications
