SOA Suite 12c introduced a number of new adapters. One of them is the LDAP Adapter. In several earlier articles on this blog (for example https://technology.amis.nl/2014/08/08/oracle-soa-suite-12c-ldapadapter-tutorial/ by Maarten Smeets), we have described how to set up and configure the LDAP adapter and how to use it in conjunction with the ApacheDS open source LDAP directory. Of course, this adapter is also supported with Microsoft Active Directory and Oracle’s OID, OVD and OUD.
In this article, I take the next step with the LDAP Adapter. I will demonstrate how to create a SOA composite that queries an LDAP directory for the details of a specific user account. This article continues where my earlier post – SOA Suite 12c: Creating user accounts in ApacheDS using the LDAP adapter (inspired by Maarten Smeets) – left off. I will assume the same set up, with ApacheDS as the LDAP Directory and the configuration of the LDAP Adapter connection already performed.
I want to create a service operation that takes a user id (uid attribute) as input and returns a selected set of details from the entry for that user in the LDAP directory. Here is an example of such an LDAP entry:
The service call – request and response – is executed in SoapUI:
and the resulting flow trace in the EM FMW Control:
The SOA Composite application is very simple – one additional component compared to the previous article: the outbound LDAP adapter reference binding, configured to search for LDAP details:
LDAP Adapter binding for Search operation
Let us check the configuration of this adapter binding.
Select the IDE connection and the JNDI name for the LDAP Adapter run time connection:
Select the Search operation.
Configure the search operation:
Select the attributes that this search should return. Only select attributes that apply to the object class(es) that the entries implement:
Accept defaults on the next two pages:
and finally, press Finish:
Data Structures and Transformations
The XSD generated as a result of the adapter binding configuration looks like this:
The LdapService has been extended with a two-way operation:
supported by an extended XSD definition:
The transformation for the search filter in the request message (from inbound request to the LDAP adapter):
The code for the query:
the baseDN (the tree under which the search should be executed) is set to the ExternalStaff “folder” in the saibot.airport “partition”
The filter string is composed according the LDAP specifications (about which there is plenty material on the internet, none of it trivial it seems – see for example LDAP Filter Tutorial). The filter is set to
concat(‘(&(objectClass=person)(uid=’,/ns0:FindUserAccountRequest/ns0:UserId,’))’) which resolves to strings such as (&(objectClass=person)(uid=hendrik.ido)) – which is LDAP speak for find all entries of objectClass person and the uid attribute set to the string value hendrik.ido.
and the transformation of the query result to the response
Note: we could perhaps have extracted a more elegant organizationUnitName and managerId. At the moment, some LDAP internals are exposed in these values.
The routing rule in the Mediator is configured like this:
Source code for this article: https://github.com/lucasjellema/soasuitehandbook/tree/master/ch18/LDAPAccessor.