0
Completed

Auto-configuration for connectors and adapters.

Tony Sheehy 6 years ago • updated by anonymous 3 years ago 4

To achieve similar configuration speed/ease benefits of Event Broker v3.1, an auto-configuration process should be considered for Identity Broker v4.1.

This issue has an explicit prerequisite for IDB-932, as being able to talk to target systems will be a prerequisite to describe their object classes.

Unlike FIM Event Broker where we have to ask a number of questions about each management agent, we could describe the partitions of a Chris21 or TRIM etc. in a standard manner. This means no custom UI per instance.

Definitions of connectors are much closer to schema providers, namely many connectors can be described by dynamic/static unique identifiers. Those that can't could be described away with bespoke Alerts.

With our definitions of connectors defined in concrete, we can systematically define standard adapters. Whether they're standard would be debatable, but they would at least be a backbone for the implementation, and hopefully get us the 80/20.

Affected Versions:
Fixed by Version:

Implementation specific:

Each AgentFactory would define its own series of Connector and Adapter providers.

Each connector provider would be given an IAgentFactory, and the requisite configuration to produce an Agent. These providers would then be able to either request from the target system (or define statically) a set of potential connectors. These would be presented on the UI with a Select/Deselect option.

Underneath, the configuration would be attached to a named connector reference from the agent (similar to auto-config). At which point, the adapter provider could work with named instances without needing to know the specifics. Any required fields could be validated, but as the IDB UI handles failing configurations correctly, an alert should suffice.

In both cases, the providers would be working with Configuration only, in the same way schema providers work with configuration. In the case of Adapter providers, we could present them with a tool to get the connector configurations out based on provided names. If prerequisites are defined for adapter providers, then we can say on the UI that an adapter requires a connector "ABC", and would you like to create it. Hitting create would fire the connector provider, allowing for the adapter provider to commence.

This issue requires agents.

  • Connector providers will result in one connector, this will be given a contextual unique Identifier that can be referenced by Adapter providers
  • Adapter providers will result in one-to-many object classes, there are a number of ways of representing this:
    • Group them and show one button
    • Individual, but indication that one will create the other.