/
Overview of the EmpowerID Universal Connector

Overview of the EmpowerID Universal Connector

The EmpowerID Universal Connector was developed to address an important need expressed by organizations seeking to lower their costs and to gain more control over their IAM implementation by allowing them to use their own internal DB resources to create both simple and advanced connectors for their directories and applications. Now IT staff using common skill-sets, such as Microsoft SQL, can quickly build their own connectors without a knowledge of the EmpowerID API or its connector technology. This greatly simplifies connecting EmpowerID to a custom system, saving time by allowing staff to start building connectors immediately without specialized training and it eliminates the need to pay for professional services to build system connectors, whether of basic or advanced functionality.

How the Universal Connector Works

The Universal Connector is an out-of-the-box standard connector like the AD connector that connects to a middleware repository or queue that sits between the EmpowerID Identity Warehouse and the custom system. The Universal Connector does not connect EmpowerID directly to a target resource system for inventory or data discovery. Rather, the Universal Connector serves as bridge between that system and EmpowerID. This bridge is an intermediate SQL database, and is in fact the object to which the Universal Connector connects. Since this intermediate database is always identical for each custom application, no custom code is required for EmpowerID to bidirectionally inventory and manage users, groups, roles, and locations. In this model, organizations export the data they want EmpowerID to manage from their custom identity store to the intermediate database via their preferred technology, including scripting, an ETL tool like Microsoft SSIS, or code in the language of their choice. EmpowerID then inventories the data from that database and provisions objects in EmpowerID, such as user accounts, groups, locations, business roles and EmpowerID Persons. From a high level, the flow for this can be represented by the below image:


The Universal Connector uses a standard schema to define the types of data organizations can export to the connector. Organizations simply need to export the data to the Universal Connector's database and turn on any jobs they want to use in EmpowerID, such as the inventory, attribute flow, and password sync jobs.

The schema for the Universal Connector provides six tables for importing data:

There is no need to import data to each of these tables; organizations only need to insert the data that is relevant to them. The Universal Connector will still operate if any of the following tables are not populated with data.

  • User — This table is used to manage user information. Each record inserted into the table is represented in EmpowerID as an account that can be linked to an EmpowerID Person. The data in this table is typically used to manage users and the information associated with people.
  • Group — This table is used to manage group information. Each record inserted into the table is represented as a generic group in EmpowerID. The data in this table is typically used to represent a collection of individuals, such as the Sales team, and can also be used to represent system roles, such as the Administrator role.
  • BusinessRole — This table is used to manage Business Role information. Each record inserted into the table is represented as an External Business Role in EmpowerID that can be mapped to any EmpowerID Business Roles.
  • Location — This table is used to manage location information. Each record inserted into the table is represented as an External Location in EmpowerID. The schema for this table allows organizations to insert data to represent all possible locations to which users can belong within the organization, including departments, divisions, geographical sites, org charts and functional areas. As with the Business Role table, each location inserted into the table can be mapped to an EmpowerID Location.
  • UserGroup — This table is used to associate users with groups and define group membership.
  • UserBusinessRoleLocation — This table is used to associate users with Business Role and Location combinations. The data in this table can be used in conjunction with or as a replacement for the Business Role and Location fields in the User table.


As with any managed directory, the Universal connector can take advantage of the full capabilities of EmpowerID, including the RBAC engine, the SSO framework, as well as password synchronization, attribute flow, group membership management, provisioning and termination of accounts, all with full auditing and reporting built-in.

In addition to the above features, the Universal Connector also supports bidirectional functionality or the ability to write changes back to the managed system. This allows organizations to internally process the updates occurring in EmpowerID, either in real-time or in batches. The changes that occur to any connected object in EmpowerID can be executed directly against the custom system or sent over to a ChangeLog queue for delayed batch processing. For the bidirectional functionality to be processed by EmpowerID, some basic operations, such as the Update operation, the Create operation, the Delete operation, etc., need to be defined by the organization. If the connector is set to not use the ChangeLog queue, any changes occurring to its objects will be executed immediately; otherwise, those changes will be sent to the queue. EmpowerID provides an out-of-the-box job, called the "Universal Connector Inbox Processor" job, to claim and process any changes in the batch queue. Organizations can, however, choose not to implement these functions and directly claim the changes from the queue, processing them using their preferred technology.


In addition to writing changes out to the ChangeLog table (if enabled), EmpowerID writes all changes occurring to managed information to its own logs, like in any other connector. These logs present detailed information about those changes, including when they happened, who initiated them, the source of the change, and more. T