Skip to end of metadata
Go to start of metadata


Some documentation explaining the source code for the LDAP integration component for KIM

Current Version



Attribute Mappers
System Parameters
Module and Class Structure
Release Notes
Changes and Modifications

Developer Setup

Instructions for developers to setup environments in order to maintain the software module. These instructions are intended for Eclipse users. Those that are not Eclipse users will need to make their own adjustments to the instructions.

Follow Rice Integration Steps

Enable Dependency Management

Technical Details

Details on modifications made to Rice or elsewhere for this integration.

Setup Spring LDAP

Modifications to spring-kim.xml File

The following was added to connect Spring LDAP

The Kuali Rice ParameterService is used to store the map between KIM and LDAP attributes. Still, many attribute names are stored in a constants class populated through Spring. See below

The constants class as well as the Spring LDAP integration and Kuali Rice ParameterService are injected into the LdapPrincipalDaoImpl instance.

The LdapPrincipalDaoImpl is an implementation of PrincipalDao which is delegated by the LdapIdentityServiceImpl. The LdapPrincipalDaoImpl connects to LDAP and maps the principal and entity information into KIM domain objects.

Implement/Override Methods in IdentityService

Create PrincipalDao for searching for Principal/Entity information from LDAP.

Retrieving LDAP Information as KIM Domain Objects

Spring LDAP offers a ContextMapper interface for these kinds of mappings; therefore, all of the mappings are in pure java. This is how KimPrincipal is mapped from LDAP.

contextMappers is an instance map created for holding ContextMapper instances. Each DTO type has a mapper associated with it for retrieving the desired information from LDAP. Notice the use of getKimConstants(). This is how constant property names are used in the mapping. Also, notice that here the ParameterService is not used. The ParameterService is only used for mapping KIM criteria in lookup scenarios. When retrieving information from LDAP, the ParameterService is entirely useless. The ContextMapper is used instead. It gives more flexibility when mapping attributes of a specific class. Below is how the ContextMapper is actually used.

Spring LDAP gives a very flexible API for querying Directory-Based systems. The search() method takes advantage of several classes from the API in order to create a fairly generic query of LDAP. On the last line, the LdapTemplate is used with a verb—ContextMapper— retrieved from the contextMappers map. It is retrieved by passing through the desired type; therefore, in the case of searching for a KimPrincipal we would use something like this:

Again, there isn’t any need for the ParameterService yet because we know exactly what we want from LDAP.

Using Mapping KIM Attributes to LDAP Attributes for Lookups

KIM has an API method called lookupEntityDefaultInfo which is used by Kuali Lookups for querying information. The call will provide a map of information in terms of KIM attributes. This means that the map or search criteria is pretty meaningless to LDAP or any Directory-based service for that matter. The KIM attributes need to be mapped to LDAP attributes in order for the query to be made. For this, the ParameterService is used.

By using regular expressions and storing parameters in the database for retrieval by the ParameterService, the task of mapping KIM attributes to LDAP attributes is pretty trivial.

Release Notes

Changes and Modifications


  • No labels