didmos2 Provisioner is a software package that allows the provisioning of an OpenLDAP database to target systems. It transfers new created user objects as well as every modification to the configured target systems. The following picture shows the flow of didmos2 Provisioner:
On the one hand, didmos2 Provisioner is based on the OpenLDAP access log (blue box) to learn about data changes and to generate individual documents from it. On the other hand, Rabbit MQ is used to forward these documents to the systems responsible for the operation of the target systems, called workers . The seamless and secure transfer of documents is guaranteed by RabbitMQ even in the event of network failures.
RA (Requesting Authority, green box) is responsible for collecting data changes in individual documents. OpenLDAP Access Log is queried at regular intervals with a search filter to be configured for data changes. For each entry found in the access log, a SCIM document is generated (configurable) for each target system concerned, and stored in a temporary queue in RabbitMQ that is specific to the object concerned (red box). Change documents for the same object are stored in the same queue.
The associated worker is notified by a permanent queue. There are one or more workers (scalable as required) per target system. The worker reads the job from his permanent queue and thus knows from which temporary queue the SCIM documents can be obtained. The attribute mapping SCIM↔Target System is configurable. Each document is transmitted to the target system via the ICF interface (Identity Connector Framework) and the status is stored in a temporary queue as a SCIM document, which is also processed by another worker (response worker, gray box). The response worker receives the document stating whether and which actions should be carried out on the didmos2 backend. Communication with didmos2 backend again takes place via a corresponding ICF connector.
As already mentioned, the communication between didmos2 Provisioner and the target systems takes place via so called ICF connectors. ICF is a standard interface designed for the transfer of identity data.
The following ICF connectors are currently supported:
- SCIM connector (provided by DAASI International and used for various worker implementations for communication with e.g. didmos Core and other systems)
- LDAP connector (provided by Evolveum)
- Active Directory LDAP connector (provided by Evolveum)
- Gluu Connector (provided by DAASI to synchronize and provision data to GLUU)
Connectors for other systems can be developed and integrated.
Overview of configuration parameters
|The name of the RabbitMQ queue from where the worker gets the requests
|The name of the RabbitMQ queue to which the worker puts the responses
|The time in seconds to wait before retrying an action
|RabbitMQ server URL
|RabbitMQ server port
|RabbitMQ user name
|RabbitMQ user password
didmos2 backend connector parameters
|The backend REST URL
|didmos2 user name for basic authentication
|didmos2 user password for basic authentication
|different resourcetypes sent by the RA
|matching Objectclasses to resourcetypes (order of entries ind the list =^ mapping)
|matching endpoints at didmos2 BE to objectclasses / resourcetypes (order of entries ind the list =^ mapping)
LDAP/AD LDAP connector parameters (see also https://wiki.evolveum.com)
|LDAP server name
|LDAP server port
Whether connector skips certificate validity check against its default truststore (e.g. Java cacerts)
Set of security protocols that are acceptable for protocol negotiation
|Timeout to connect (in milliseconds)
|Maximum number of attempts to retrieve the entry or to re-try the operation
This number is applicable in replicated topology when handling connection failures and re-trying on another server, when following referrals and in similar situations
The authentication mechanism to use
|The base DN that the connector will use if the base DN is not specified explicitly
|The DN of the object to bind to
|Use permissive modify LDAP control for modify operations
Possible values: never, auto, always
|Specifies strategy of using paging mechanisms such as VLV or Simple Paged Results
Possible values: none, auto, spr, vlv
Default value: auto
|Hash the passwords with a specified algorithm before they are sent to the server
|Name of the attribute which will be used as ICF UID
|Operational attributes that apply to all object classes
|If set to true, adds all additional structural object classes without children to the auxiliary object classes list on the connector
Additional AD and LDAP connector parameters (see also https://wiki.evolveum.com)
|Object class to use for user accounts. Default: user
|Object class to use for user accounts. Default: group
|Group member attribute name. Default: member
Strategy of global catalog usage
If set to true then the connector will try to search all defined servers for an entry if all other attempts fail
If set to false then the connector will interpret the content of userAccountControl attribute and will decompose it to pseudo-attributes for enabled state, lockout, etc.
If set to true, then the connector will use native AD schema definition.
Extend the declared AD schema with tweaks that allow practical usage of the schema.
Enables inclusion of explicit object category filter in all searches. Normally the connector would derive search filter only based on the attributes specified in the query. E.g. (&(uid=foo)(cn=bar)).
If set to true then the connector will automatically add default object category to all created objects.
If set to true then the connector will force password change at next log-on every time when the password is changed. If set to false (default) the password change at next log-on will not be forced.
The mechanism that will be used to execute scripts on resource.
Default value: winrm