MuleSoft LDAP Connector With Example

LDAP is commonly used as a centralized directory for identities and other structured directory information. Applications can query LDAP to validate users, retrieve attributes, and discover directory entries without duplicating identity data across systems.

This article demonstrates how a Mule application can query an LDAP directory through the MuleSoft LDAP Connector.

Version context: This example was originally built with Mule 3.x, Anypoint Studio, and the community LDAP connector available at that time. The exact installation steps and connector packaging are historical, but the integration pattern—configure a directory connection, execute a search, and handle zero, one, or multiple results—remains broadly applicable.

Test Directory

The original example used the Forum Systems public LDAP test server so the flow could be demonstrated without installing a local LDAP server.

A separate LDAP browser such as JXplorer can be useful for validating directory structure and test data before troubleshooting an integration flow.

Step 1: Install the LDAP Connector

In the Anypoint Studio version used for this example, the LDAP Connector was installed through Help → Install New Software using the Anypoint Connectors update site.

Step 2: Add the LDAP Module

The project also required the LDAP module dependency. The original Mule 3.7.3 setup could still produce an Invalid content found starting with ldap: error after adding the Maven dependency, so the connector JAR was also placed in the embedded runtime's user directory and Anypoint Studio was restarted.

<dependency>
    <groupId>org.mule.modules</groupId>
    <artifactId>mule-module-ldap</artifactId>
    <version>RELEASE</version>
    <scope>provided</scope>
</dependency>

This is a version-specific workaround from the Mule 3.x environment and should not be assumed to apply to current Mule runtimes.

Step 3: Create the Mule Flow

The flow exposes an HTTP endpoint, checks the incoming uid query parameter, and executes an LDAP search when the parameter is present.

Mule Flow XML

<?xml version="1.0" encoding="UTF-8"?>


<mule xmlns:json="http://www.mulesoft.org/schema/mule/json"
	xmlns:ldap="http://www.mulesoft.org/schema/mule/ldap" xmlns:http="http://www.mulesoft.org/schema/mule/http"
	xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns="http://www.mulesoft.org/schema/mule/core"
	xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
	xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd
http://www.mulesoft.org/schema/mule/ldap http://www.mulesoft.org/schema/mule/ldap/current/mule-ldap.xsd
http://www.mulesoft.org/schema/mule/json http://www.mulesoft.org/schema/mule/json/current/mule-json.xsd">


	<http:listener-config name="HTTP_Listener_Configuration"
		host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration" />
	<ldap:config name="LDAP" authDn="cn=read-only-admin,dc=example,dc=com"
		authPassword="password" url="ldap://ldap.forumsys.com" doc:name="LDAP" />


	<flow name="LdapSearch">
		<http:listener config-ref="HTTP_Listener_Configuration"
			path="/ldapsearch" doc:name="HTTP" />
		<choice doc:name="Choice on HTTP Param UID">
			<when expression="#[message.inboundProperties.'http.query.params'.uid != empty]">
				<set-variable variableName="UID"
					value="#[message.inboundProperties.'http.query.params'.uid]"
					doc:name="Variable UID" />
				<logger
					message="LdapSearch : Request received with UID parameter as : #[flowVars['UID']]"
					level="INFO" doc:name="Logger Requested UID" />
				<ldap:search config-ref="LDAP" baseDn="dc=example,dc=com"
					filter="(uid=#[flowVars['UID']])" doc:name="LDAP Search Operation" />
				<logger message="LdapSearch : Result : #[payload]" level="INFO"
					doc:name="Logger LDAP Search Result" />
			</when>
			<otherwise>
				<logger message="LdapSearch : Request received without UID parameter"
					level="INFO" doc:name="Logger Without UID Parameter" />
			</otherwise>
		</choice>
	</flow>
</mule>

Step 4: Validate the Search Behavior

The original test used a REST client to invoke the HTTP listener. The useful part of the exercise is validating how the flow behaves for different search outcomes.

Case A: Request Without uid

GET http://localhost:8081/ldapsearch

The flow detects that the query parameter is missing and logs:

LdapSearch : Request received without UID parameter

Case B: uid Provided but No Entry Found

GET http://localhost:8081/ldapsearch?uid=123

The LDAP search returns an empty collection:

LdapSearch : Result : []

Case C: Single LDAP Entry Returned

GET http://localhost:8081/ldapsearch?uid=euler

A matching directory entry is returned with attributes such as uid, mail, sn, cn, and objectClass.

Case D: Multiple LDAP Entries Returned

A broader search expression can return multiple directory entries. In the original test, a wildcard search for values beginning with e returned several matching users.

The key application concern is not only executing the LDAP operation successfully, but also handling the cardinality of the result correctly: zero matches, one match, or multiple matches can require different downstream behavior.

Design Considerations

For production integrations, the sample should be extended with explicit error handling, timeouts, secure transport where required, credential management, and response behavior appropriate to the API contract. A temporary LDAP connectivity problem should not simply be retried blindly by the caller.

Takeaway

An LDAP integration flow is conceptually simple: establish a directory connection, construct a search filter, execute the search, and interpret the result. The implementation details vary by connector and Mule version, but the integration pattern and error-handling concerns remain consistent.