ForgeRock Identity Connector Framework (ICF)
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.
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.