Fork me on GitHub

n. Slang a rough lawless young Kuali developer.
[perhaps variant of Houlihan, Irish surname]
kualiganism n

Blog of an rSmart Java Developer. Full of code examples, solutions, best practices, et al.

Tuesday, April 3, 2012

Rice KIM LDAP and Embedded Apache DS


While KIM supports LDAP Integration for identity management, it is difficult for developers to work in a similar environment to that the code will actually be deployed to. For example, if my DEV, TST, STG, and PRD environments all connect to LDAP and there is a problem with the actual LDAP mappings, it is a hassle to test or develop a fix because my local development environment does not connect to LDAP. I would have to configure it to do that. Once it did, I probably do not have the same datasource that is being used. How can I test?

KIM LDAP Integration Test

Recently the Rice team came up with this integration test (see that will test the LDAP Integration. It runs against a sample dataset. The trouble is, it is started entirely using the spring LdapTestUtils. See below:

That's not very handy if you want to use this for development. You could just run your integration tests I suppose. I thought to myself though, that it would be really nice to be able to have a running LDAP Reference Implementation within my development environment anyway. I also thought that the java approach used by the KIM LDAP Integration test was a little excessive and bootstrapping Spring in the integration test would be much more preferred. I decided it would be worth a shot. That way the integration tests and a reference implementation can all run out of a common setup.

Embedded Apache DS

What I did was, I modified my KFS Overlay Reference Implementation, to include an embedded Apache DS instance.

apacheds Profile

The first thing I did was create an apacheds profile in my pom.xml

You can see that I have a dependency on apacheds 1.5.7. I'm not actually using this...yet. I currently use the Spring ldap utils. 1.5.7 is a transitional version to the new apacheds 2.0. apacheds is kinda going through the same thing as what Rice went through. After 1.0.2, they created this thing called the BBB (Big Bang Branch). They are basically rewriting the software that will be released in 2.0. Sounds familiar, right? Anyway, back from the tangent. The plan is eventually using 1.5.7 and 2.0, but for now I stick with 1.0.2. If it is good enough for Spring, it is good enough for me.
As I mentioned, I use the spring ldap utils and of course, I had to add a dependency to rice-ldap. See below:

I added a few files to the core module:
            |   \->com
            |       \->rsmart
            |           \->kuali
            |               \->rice
            |                   \->kim
            |                       \->ldap
            |                           \-> 
            |                           |->service
            |                               \->impl
            |                                   \->
                                        |   \->KIMLdapServerSpringBeans.xml
                                        |   |-> KIMLdapSpringBeans.xml

This is really just configuration. It is loaded into spring at startup and handles loading bootstrap data as well as starting the server. No big deal. I set it to configure in the KIMLdapServerSpringBeans.xml.


There are just 2 beans setup here.
  • embeddedLdapServer
  • configuration
. One is our ApacheDsEmbeddedServer. The other is a MutableServerStartupConfiguration. The MutableServerStartupConfiguration is what is actually starting the apacheds. You can see that configuration is actually a reference that is applied to the embeddedLdapServer. The needs the configuration and connection information because it actually connects to the running apacheds instance to load data stored in the demo.ldif.

You may notice there are some properties set within the ${} tags. These properties are defined in 2 files. One is located in web/src/main/filters/ and the other is in config/src/main/filters/


These properties are later added to the file at build time. You can see my mappings are setup here. You want this to look exactly how your production environment will work.


These properties are later added to the file at build time. You can see that this is where I setup my credentials.

Running it

The command I have been using to kick build a kfs-dev.war with an embedded ldap server is:
% mvn -Pmysql,apacheds clean package

If I want to build a war without an LDAP server and ignore all my ldap settings, I just use:
% mvn -Pmysql clean package

Getting it

If you want to setup something like this for yourself, just refer to this blog post and you can always pull/fork my code from KFS Overlay Reference Implementation

1 comment: