Connector Development v4.1 Architecture


Connectors in Identity Broker represent subsets of identity information from a target system. See Connector Overview for a full description. Identity Broker can then take this subset of information and through its data modelling engine, expose this information in a format required for identity management. As such, when designing a connector care should be taken to not double up on functionality already provided by Identity Broker. In a practical sense this might look like the following:

Image 4668

In the above, we consider a person to be its details (first name, last name etc.) but also whether he/she has been terminated. The person details are represented through a details connector and terminations through a termination connector.

Role of Connectors

Identity Broker uses these connectors to perform any of the following operations:

  • Import All
  • Import Changes
  • Add Entities
  • Update Entities
  • Delete Entities
  • Modify Anchor – Changes the key of a particular entity
  • Change / Set Password

Role of Agents

Agents perform the role of encapsulating connection information for an individual target identity store, so that it can be shared across one or more connectors. This provides significant flexibility to implementers, specifically because:

  1. If multiple connectors point to the same system, changing the connection information in the agent changes all connectors (think passwords)
  2. When migrating from DEV to PROD environments, the agents should only need to be changed, while the data modelling logic remains untouched.

Plug In Architecture

Custom connectors and agents are registered to Identity Broker through two separate plug-in mechanisms. Specifically, one on the service side and one on the user-interface end. This enables developers to attach the custom connectors, agents, and user-interface parts.

User Interface

The UNIFY Identity Broker Management Studio, shipped with all copies of the UNIFY Identity Broker Service, has been written in the ASP.NET MVC3 (Razor) web-stack. Like the service, the studio has support for plugins, in the form of custom user interface parts.

Writing custom UI parts for the UNIFY Identity Broker Management Studio requires a basic understanding of the Model-View-Controller (MVC) paradigm, and the implementation of it in MVC3 with the Razor View Engine. (see.

The plugin architecture into the UNIFY Identity Broker Management Studio is defined by creating custom Controllers. These controllers are registered to the studio on start-up, and can be subsequently accessed through:


For specific plugins, such as connectors, this is achieved by registering implementations of specific base controller types (ExtensibleAgentController, and ExtensibleConnectorController). These controllers define a set of base methods that are wired into Identity Broker: Create; Edit; and Display.

Is this article helpful for you?