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.
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. This information can then be audited and acted upon as needed. |
The following image shows the flow that occurs between the custom system and EmpowerID when the ChangeLog is in place. A description of the steps follows. For most situations where a write-back connector is needed, implementing a real-time .NET IChangeLogProcessor is the preferred method versus using the data written out to the change log table.
Step 1 — The organization selects the data they want EmpowerID to manage according to the schema of the Universal Connector and imports that data into the Universal Connector database.
Step 2 — The inventory process is initiated by the organization and executed by EmpowerID. EmpowerID will pull changes from the universal Connector on a scheduled basis, initially importing all data, and delta information from that point forward.
Step 3a — If the ChangeLog Processor is disabled (preferred), changes will be executed immediately using any application specific change processing logic.
Step 3b — If the ChangeLog Processor is enabled, it captures all changes made to objects—either by users running EmpowerID workflows against those object or by EmpowerID provisioning policies—in the account store representing the custom directory or application, and writes those changes to the ChangeLog table of the SQL database associated with that account store.
When you bring the user records from your custom application into the Universal Connector database and enable EmpowerID to inventory the database, EmpowerID performs a number of tasks to process those accounts in accordance with the policies you have applied to the Universal Connector account store. These tasks include the following:
EmpowerID creates an account record in the Account table of the EmpowerID Identity Warehouse for each unique record it discovers in the User table of the Universal Connector database.
EmpowerID then evaluates the records in the Account table of the EmpowerID Identity Warehouse to determine whether those records are owned by users. The criteria for this evaluation is whether those records have valid FirstName and LastName properties (the properties are not null). If an account record does not meet this criteria, EmpowerID simply ignores it and moves on to evaluate the next record. If an account record does meet the criteria, EmpowerID marks it as belonging to a user, captures all the unique identifier information for that account, maps the account to the Universal Connector account store for attribute flow, and then executes a set of stored procedures, known as the "Join" and "Provision" rules. These rules, in conjunction with certain user-defined settings, tell EmpowerID what relationship, if any, it should create between inventoried user accounts and EmpowerID Persons. As a whole, this process of evaluating, joining and provisioning is handled by what is known in EmpowerID as the "Account Inbox."
Once EmpowerID has provisioned a Person from the account, it places that Person in the default Business Role and Location configured for the Universal Connector account store and applies to that Person any applicable policies you have configured for your environment. These policies can include:
Resource Entitlement (RET) Policies: - These policies are processed by the RET Inbox to ensure that each qualified Person receives any resources specified by your RET or Provisioning policies. These resource can include Active Directory user accounts, Exchange mailboxes and home folders.
Dynamic Group Membership Policies - These policies allow you to dynamically assign people to groups using role-based delegations, such as the Business Role and Location of those people.
Default Attribute Values Policies - These policies allow you to assign default Person attribute values to a Person based on that Person's primary Business Role and Location. If attribute flow is enabled, EmpowerID will then push these default attribute values to each connected directory in which the Person has an account.
The following image shows the above processes from a high level.
