LDAP Adapter Activity

The MDW LDAP Adapter Activity provides the ability to query an LDAP directory for entities and attributes, and to bind the results to process variables.
Note: In order to connect to the LDAP servers, your ServiceMix/Fuse or Tomcat server must be configured with the configured with the appropriate certificates by default. For ServiceMix/Fuse reference the jks file as follows in etc/system.properties:
javax.net.ssl.trustStore=etc/MyCA.jks
In your local development environment this should happen automatically when you run the buildConfig Ant target.

Design Attributes

The basic design parameters for configuring an LDAP Adapter Activity are illustrated in the screenshot below. The first five attributes use the special notation to indicate that their runtime values are retrieved from application properties. In fact, these five properties should already exist in your ApplicationProperties.xml file, and would only need to be changed from the defaults if you want to connect to a different server or with different application credentials. The "Search Context" attribute specifies corresponds to what's called the base object for the search in LDAP parlance. This constitutes the starting point for your search. The "Search Filter" attribute identifies the criteria to narrow down the search results. The search filter syntax is a logical expression in prefix notation (where the logical operator precedes its arguments). Inside your expression, you can embed dynamic process variable values according to the usual MDW binding expressions syntax. For example, in the screenshot we are searching for the user whose CUID matches the process variable named "cuid".



The table below lists the symbols used for creating filters. For more information, refer to Sun's JNDI LDAP Tutorial.

Symbol Description
& conjunction (i.e., and -- all in list must be true)
| disjunction (i.e., or -- one or more alternatives must be true)
! negation (i.e., not -- the item being negated must not be true)
= equality (according to the matching rule of the attribute)
~= approximate equality (according to the matching rule of the attribute)
>= greater than (according to the matching rule of the attribute)
<= less than (according to the matching rule of the attribute)
=* presence (i.e., the entry must have the attribute but its value is irrelevant)
* wildcard (indicates zero or more characters can occur in that position); used when specifying attribute values to match
\ escape (for escaping '*', '(', or ')' when they occur inside an attribute value)


Bindings

The results from your LDAP directory search are bound to process variables as illustrated in the following screenshot. For instance, in our example we are binding the LDAP attribute "departmentname" to our process variable "department".



If you expect multiple matching results from your search, you should bind to a collections variable type. For example, if your search filter was "(sn=${lastName})", you might expect n matching results, corresponding to the number of people whose last names match the process variable called "lastName". In this case, you could bind a variable of type java.lang.String[] to the uid attribute to receive all the CUIDs, and a variable of type java.lang.Integer[] to the mnetid attribute to receive those values. After execution, each of these array variables would contain n elements, populated with the retrieved values.

You can bind the entire result set to a document variable by using the implicit "results" attribute (see screenshot). If the document variable is an XML document type, its value will be populated with an XML representation of the first match based on the MDW user schema type. If the document variable is of type java.lang.Object, then it will be populated with a Map<String,List<Object>> value containing the names and corresponding value(s) for each LDAP attribute. Either way, the LDAP results are passed to your Adapter post script as "(Map<String,List<Object>>)results" for any desired custom handling. Adapter post script is configured using the Script tab.



Troubleshooting: if you encounter an exception like the following, then it means you need to download the JCE 6 Unlimited Strength Jurisdiction Policy Files for JDK 1.6.
Or for JRE 1.7 JCE 7 Unlimited Strength Jurisdiction Policy Files 
java.security.InvalidKeyException: Illegal key size or default parameters