Understanding OIM’s Generic Technology Connector

Anyone that has implemented any kind of provisioning solution knows that the most difficult part of deploying a solution is creating the connectors –  those components that allow the provisioning system to integrate with the managed target systems. Oracle sells a number of application-specific connectors for OIM that are designed for target systems such as MS Active Directory and Peoplesoft User Management. These connectors are built on the specific APIs that the target system exposes, supporting deep integration with support for a rich set of provisioning operations.

However, for applications that are not supported out of the box, or custom applications that customers have built themselves, building a connector can be an arduous task. It takes planning and resources (both in time and manpower). Quite often, APIs are simply not available for build a good connector. And the number of applications in an enterprise that need to be managed can prove overwhelming to a small IdM team.

Introducing the Generic Technology Connector
This is where the Generic Technology Connector steps in. Introduced in OIM 9.0.3, the name is actually a misnomer. The GTC is really a wizard that provides an alternative connector development environment to rapidly create all the necessary functional components that make up a target system connector in OIM. It’s power comes from the way it leverages standardized mechanisms and tools instead of application specific APIs. The GTC framework also eschews the more powerful, but complex, process-based connector approach for a far simpler dataflow-based connector approach.


The GTC is one part of a three pronged comprehensive integration offering (see diagram above). The GTC allows customers to easily build connectors for target systems that support standard integration mechanisms like flat-file imports via FTP, or SPML-based provisioning over Web Services. Target systems that do not need complicated provisioning process flows can be quickly brought under management in OIM, dramatically reducing the deployment timelines. While a GTC-based connector does not have all the rich capabilities an API-based application-specific connector has, the fact is that for most applications the deeper integration capabilities are not needed.

Architecture of a GTC-based Connector
The following diagram shows the component level architecture of a connector (supporting both provisioning and reconciliation) built using the GTC (click on the image for a larger view).

The GTC framework provides basic building blocks that are used to rapidly assemble a custom connector. The architecture shows the dependence of the GTC framework on the data migration aspect of the connector. The building blocks are:

  • Reconciliation
    • Reconciliation Transport Provider: This provider is responsible to moving the reconciled data from the target system into OIM.
    • Reconciliation Format Provider: This provider parses the message received from the target system (that contains the reconciled data) into a data structure that can be understood by OIM’s reconciliation engine.
    • Validation Provider: This provider validates any data received before passing it on to OIM’s reconciliation engine.
  • Provisioning
    • Provisioning Format Provider: This provider converts OIM provisioning data into a format that is supported by the target system.
    • Provisioning Transport Provider: This provider carries the provisioning message received from the Provisioning Format Provider to the target system.

The term Provider is pretty ubiquitous in the above architecture, and represents one of the fundamental features of the GTC framework. OIM administrators can add to the building blocks that make up the GTC framework simply by defining and dropping in new providers supporting additional technologies/mechanisms. The Transport Providers support standard communication protocols like HTTP, SMTP, FTP and Web Services. Format Providers support generic message formats such as CSV, SPML and LDIF.

The GTC Framework builds on top of the existing connector framework in OIM, leveraging all of it’s existing capabilities (like auditing, security, export/import capability etc).

Developer Experience
A major feature of the GTC is the improved developer experience. The GTC employs a web-based point-and-click graphical wizard that clearly shows to the user the data flows that they are defining within the connector. It stores in metadata all the configuration information regarding the connector, so that it can reload the GTC view of the connector and enable ongoing maintenence of the connector in the same graphical environment. Since the GTC builds the connector using the standard connector framework behind the scenes, the developer is actually free to go into the standard OIM development environment and make further modifications to the generated connector. However, once the GTC-based connector has been “customized” in this manner, it can no longer be maintained using the GTC.

For more information, visit the page for Oracle Identity Manager at oracle.com/identity.

9 Comments