IDM 7.2.2

ForgeRock Identity Connector Framework (ICF)

Connectors continue to be released outside the IDM release. For the latest documentation, refer to the ICF documentation.

ICF provides a common interface to allow identity services access to the resources that contain user information. IDM loads the ICF API as one of its OSGi modules. ICF uses connectors to separate the IDM implementation from the dependencies of the resource to which IDM is connecting. A specific connector is required for each remote resource. Connectors can run locally (on the IDM host) or remotely.

Local connectors are loaded by ICF as regular bundles in the OSGi container. Most connectors run locally. Remote connectors must be executed on a remote connector server . If a resource requires access libraries that cannot be included as part of the IDM process, you must use a connector server. For example, ICF connects to Microsoft Active Directory through a remote connector server that is implemented as a .NET service.

Connections to remote connector servers are configured in a single connector info provider configuration file, located in your project’s conf/ directory.

Connectors themselves are configured through provisioner files. One provisioner file must exist for each connector. Provisioner files are named provisioner.openicf-name where name corresponds to the name of the connector, and are also located in the conf/ directory.

A number of sample connector configurations are available in the openidm/samples/example-configurations/provisioners directory. To use these connectors, edit the configuration files as required, and copy them to your project’s conf/ directory.

The following figure shows how IDM connects to resources by using connectors and remote connector servers. The figure shows one local connector (LDAP) and two remote connectors (Scripted SQL and PowerShell). In this example, the remote Scripted SQL connector uses a remote Java connector server. The remote PowerShell connector always requires a remote .NET connector server.

The figure shows the basic architecture of ICF with local and remote connectors.
Figure 1. How IDM Uses the ICF Framework and Connectors

Connectors that use the .NET framework must run remotely. Java connectors can be run locally or remotely. You might run a Java connector remotely for security reasons (firewall constraints), for geographical reasons, or if the JVM version that is required by the connector conflicts with the JVM version that is required by IDM.

ICF configuration properties used by IDM

Use the following properties (in resolver/boot.properties) to specify how ICF should manage operations on external resources:

openidm.icf.retry.enabled

Specifies whether ICF operations should be retried, if network connectivity is lost. False by default.

openidm.icf.retry.delaySeconds

Delay, in seconds, between ICF retry operations. 10 by default.

openidm.icf.retry.updates.enabled

Specifies whether ICF update operations should be retried, if network connectivity is lost. False by default.

openidm.icf.retry.maxRetries

If openidm.icf.retry.enabled=true, specifies the maximum number of ICF operation retry attempts when network connectivity is lost. 12 by default.