April 13, 2018 at 10:03 am #21475FabienParticipant
I am testing an LDAP connector (1.4.x) with a very big set of custom attributes defined in the properties of objectType “account”.
When I check the OpenDJ logs (target) I can see the search filter just before a sync containing all the attributes available in the connector provisioner file, this creates a lot of overhead in the logs and DB (and a long river when you scroll :) ).
SEARCH REQ conn=15 op=396 msgID=397 base=”dc=example,dc=com” scope=wholeSubtree filter=”(&(entryUUID=eb1ff4d6-fd77-442a-a886-cb6d62ac0aa3)(&(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(objectClass=customObjectClass)))” attrs=”customattribute1,customattribute2,…customattribute1000″
How can I limit the search request of attributes to attrs=”ALL” from OpenIDM during requests routed through my mapping and provisioner file?
I tried to modify the request, but could only alter the filter for objectCLasses and using attributesToSynchronize is not an option here because potentially all the attributes in the provisioner file are in scope.
Even better would be to have control of the ATTRS TO GET list, is that possible?
Any ideas how to shorten the search request from the LDAP connector?April 14, 2018 at 6:06 pm #21482Bill NelsonParticipant
You are kind of in a catch-22 situation; let me explain.
The LDAP provisioner file that you create defines the attributes that you want exposed in the LDAP server on a per object (account, group, etc.) basis. Think of it as a “filter” of the entire universe of attributes that can be retrieved fro the LDAP server – in many cases you don’t want access to all attributes, may not be allowed access to all attributes, and in some cases, want to dictate the types of interactions that you are allowed to have with each attribute (is it readable, writable, etc.).
In all cases, you need to create a one to one mapping between the native name of the attribute from the LDAP server and the name by which you refer to it in OpenIDM. If you don’t clearly specify (at a granular level) the attributes you want exposed, then what happens when an entry in LDAP takes on more attributes than you are prepared for? Then you end up retrieving more attributes then you can handle (since you don’t have clear mappings to OpenIDM object property names) and then you have no real way of referencing these attributes in your processing logic (i.e. mappings).
So, unfortunately, the only way to do this is to create the filter that completely corresponds to the attributes that you want exposed via the LDAP connector and yes, does create a somewhat lengthy search filter entry in the LDAP access log.
Are there other alternatives? Absolutely. Instead of using the LDAP connector, consider using a scripted connector and make your calls using native LDAP methods via groovy. You will have to create much of the logic that is already built into the OOTB LDAP connector, but if the long entries in your LDAP access log bother you that much, then at least you have an option.
billApril 16, 2018 at 1:15 pm #21488FabienParticipant
Thanks for your reply, I was afraid this would be the case.
I also have this issue while provisioning in the end because an update of a user triggers an update of every attribute defined on the connector (with a lot of null values) even when the calculated target object (mapping) only contains non-empty attributes. This results in a lot of overhead also in the audit logs of OpenIDM, even on a testing environment.
The LDAP in scope is owned by a third-party so I am very limited in changes on that side, but let’s say I would include all the custom attributes in an array called roles and abstract those custom attributes from the connector.
OpenIDM would then manage this array as one single attribute.
Can OpenDJ parse attributes included in a array and map those to the exisiting schema? Would that be difficult to implement?
You must be logged in to reply to this topic.