IBM Integration Bus 10.0.0.15 is now available

We’re pleased to announce that IBM Integration Bus 10.0.0.15 is now available! In fact, this latest release came out at the end of last year, so now that Christmas and New Year festivities are out of the way, what better time to have a deeper exploration of one of the new features this fix pack has to offer.

Configuring IBM Integration Bus with multiple LDAP Server connections for High Availability

With Fix Pack 15, IBM Integration Bus now has the ability to fail over its connection to one or more alternate LDAP servers, when authenticating connections delivering inbound data to a deployed message flow. IBM Integration Bus can be configured to use an LDAP server for a couple of different purposes:

When authenticating administration requests which change the IIB product’s configuration
When authenticating requests to deployed message flows

This post concentrates on the latter of these capabilities and what happens when you have secured a message flow to use an LDAP server for authentication. First of all we’ll have a quick reminder of how the standard features work when interacting with an LDAP server, and then explore the new settings as part of a worked scenario.

When you deploy a message flow to the runtime, on the BAR file which you deploy you can nominate the name of a Security Profile to be used by the runtime. This setting is available at the message flow scope or, as in this example, on an HTTPInput node:

Consider a very simple runtime set-up as follows:

mqsicreatebroker IIB10LDAPTEST
mqsistart IIB10LDAPTEST
mqsicreateexecutiongroup IIB10LDAPTEST -e default
mqsisetdbparms IIB10LDAPTEST -n ldap::ibmexample1 -u "uid=admin,ou=system" -p admin123
mqsicreateconfigurableservice IIB10LDAPTEST -c SecurityProfiles -o LDAP -n AlternateServers,authentication,authenticationConfig,authorization,authorizationConfig,propagation,rejectBlankpassword -v "\"ldap://ibmexample2:10390\",LDAP,\"ldap://ibmexample1:10389/dc=example,dc=com\",NONE,\"\",TRUE,TRUE
mqsistop IIB10LDAPTEST
mqsistart IIB10LDAPTEST

The mqsisetdbparms command tells the integration node which userid (uid=admin,ou=system) and password (admin123) to use when communicating with the LDAP server located on host ibmexample1. The same userid and password will be used when communicating with the AlternateServer named ibmexample2, in the case of ibmexample1 not being available.
The mqsicreateconfigurableservice command defines a SecurityProfile called LDAP which we referenced up above on the BAR file. This SecurityProfile defines the LDAP URL which should be used when doing authentication to: ldap://ibmexample1:10389/dc=example,dc=com. Note that this command also specifies a new property and value which is introduced in fix pack 15 called AlternateServers. This property lets you specify a comma-separated list of one or more alternate LDAP servers which IIB can use in the event that its primary connection becomes unavailable. More on this new parameter later!

You will very likely have your own LDAP server implementation in mind (IIB supports LDAP servers which conform to LDAPv3), but to provide a simple example, this article utilises an installation of Apache Directory Studio on Windows. In our case we have actually cheated a little (just for convenience of the demo!) and run both servers on the same physical machine, but set them up to use different ports. We’ve changed the operating system hosts file to map the hostnames ibmexample1 and ibmexample2 both to 127.0.0.1. Of course in real-life high availability scenarios your LDAP server and any alternate server definitions are likely to be on different physical machines on your network. So, in our case, we have on the same machine as IIBv10, two available LDAP servers:

An LDAP server ibmexample1

This LDAP server is set up to receive requests on port 10389
This LDAP server has an administrator user set up named admin with password admin123
Anonymous connections to ibmexample1 are not allowed

An LDAP server ibmexample2

This LDAP server is set up to receive requests on port 10390
This LDAP server has an administrator user set up named admin with password admin123
Anonymous connections to ibmexample2 are not allowed

To demonstrate the concept of IIB being capable of failing over a connection from one LDAP server to another, these two LDAP servers should be considered clones of one another:

They both have a root of “dc=example,dc=com”
Both LDAP servers have been configured with a user named Ben Thompson. Ben is defined with the same userid (bthomps) and password (password1) in both ibmexample1 and ibmexample2
Both LDAP servers have been configured with a user named Trevor Dolby. Trevor is defined with the same userid (tdolby) and password (password2) in both ibmexample1 and ibmexample2

Here’s the Apache Directory Studio view of the LDAP servers showing these user definitions:

Once you have the LDAP server(s) running, Security Profile defined, userid and passwords configured and your flow deployed, you can test the scenario. In this simple example, consider a simple message flow which just echoes your data back to you across HTTP. The screengrab below shows two separate invocations of the message flow using a simple HTTP curl client. The first invocation uses a Basic Auth header with the correct userid / password (bthomps / password1). The second invocation uses a Basic Auth header with an incorrect password (bthomps / thispasswordiswrong):

Now you have a basic scenario to LDAP working, it’s time to investigate the new AlternateServers property. To see this in action, you can run a test as follows:

Stop both your LDAP servers:
Run a simple batch script to recursively execute the same HTTP request using curl which we used up above. On a Windows platform you could use something like this for example:
```
for /l %%a in (1,1,5000) do (  curl -X POST http://localhost:7800/LDAPTestFlow -u bthomps:password1 -d helloworld)
```
When the script starts, with both LDAP servers shutdown, you should see exceptions reported like this:

In Event Viewer you should also see a connection failure:
Whilst your script is still running, start up one or both of your LDAP servers and you will immediately begin getting successful responses
You can now experiment with shutting down one (or both) of your LDAP servers again. Note that usage will only be reset to the primary server when IIB is restarted. Another important thing to note is that IIB has a securitycache component which contains a cacheTimeout property, so if you find that shutting down an LDAP server is not having an immediate effect which you expect then you may need to alter this, or use the mqsireloadsecurity command to force the immediate expiry of entries in the security cache.

We hope you’ve enjoyed this discussion of the new feature in IIBv10.0.0.15 for switching LDAP servers for high availability!