The Long-Winded Guide to setting up Amlen: LDAP

This is a section of a multi-part guide to setting up the Amlen Message Broker. If you want to see the other parts check out the Introduction/Contents.

Probably the most common way of authenticating clients with Amlen is using an LDAP server.

The Basic Flow

The MQTT client connects to Amlen and sends a username+password as part of the connect packet. Amlen sends the credentials to LDAP server and the LDAP server responds by saying whether the credentials are authorised and providing extra info (e.g. any groups the the user is in).

Trying it out

We need an LDAP server. Luckily there is one we prepared earlier:
Demo LDAP server

In order to run the demo you’ll need to be able to run containers (the script assumes docker but it’s easy to change it to podman) (as it’s openldap in a container).

1. Get the demo ldap server scripts:
   git clone https://github.com/jonquark/messagesight-demos-docker.git
cd messagesight-demos-docker
2. If using podman (if using docker, skip this step):
   git grep -rl 'sudo docker' . | xargs sed -i 's/sudo docker/sudo podman/g'
3. cd openLDAPServer
./openldap.sh build
./openldap.sh run
4. Set up the variables to connnect to Amlen REST interface (assuming we are going to run curl on the system where the Amlen Server is installed:
   export IMA_ADMIN=https://127.0.0.1:9089/ima/v1
   export IMA_USER=”admin:fish7lettuce!”
5. Add the LDAP profile (this is all one single command – if the ldap server and the amlen server are on different systems change the URL parameter to give the IP address/hostname of the host machine running the LDAP server)
   curl -X POST -k -u ${IMA_USER} -d ‘{“LDAP”:{“URL”: “ldap://localhost”,”BaseDN”: “o=IBM”,”BindDN”: “cn=Manager,o=IBM”,”BindPassword”: “msDemoPassw0rd”,”UserSuffix”: “ou=users,ou=MessageSight,o=IBM”,”GroupSuffix”: “ou=groups,ou=MessageSight,o=IBM”,”UserIdMap”: “:cn”,”GroupIdMap”: “:cn”,”GroupMemberIdMap”: “member”,”IgnoreCase”: true,”Timeout”: 10,”EnableCache”: true,”MaxConnections”: 10,”Enabled”: true}}’ https://${IMA_ADMIN}/configuration

Now we have an LDAP server running and have told Amlen where it is, we now create a security profile that requires a username and password. In the following we assume that you followed enough of the previous installation to get a client to connect to the server over TLS:

1. In the Amlen WebUI go to Server > Security Settings
2. Add a new security profile called e.g. ‘TestServerLDAP’
3. Assuming that you’ve done the first part of the TLS set up, ensure that use TLS is ticked and the test.server certificate profile is selected
4. Ensure that “Use Password Authentication” is ticked (and that “Use client certificates is NOT ticked).
5. Save the profile

Then we getting Amlen to listen on a port using the security profile:

1. In the Amlen WebUI go to Messaging>Message Hubs
2. Click on ‘DemoHub’ and then the pencil icon above the table.
3. Switch to the “Endpoints” tab
4. Click the green ‘+’ above the Endpoints Table.
5. Enter a Name for the Endpoint e.g. LDAPTestPort
6. Ensure “Enabled” is ticked
7. Choose a port (MQTT with TLS is 8883 by default but pick say 8891)
8. Choose the security profile we created above (TestServerLDAP)
9. Add the DemoConnectionPolicy (we’ll talk about policies in a future installment – for the moment we let anyone connect and pub/sub on any topic).
10. Add the DemoTopicPolicy and DemoSubscriptionPolicy
11. Save the policy

Finally we need to connect a client to the port to check that password authentication is working:

python3 client_sub_opts.py -H testserver.getting.started -P 8891 -D -t topic1/# -s --cacerts myCA.pem -u msgUser1 -p testPassw0rd

Should show the client successfully connecting and subscribing (as it uses a correct user+password combination from the demo LDAP server) but an evil hacker who doesn’t have the correct password will fail to connect:

python3 client_sub_opts.py -H testserver.getting.started -P 8891 -D -t topic1/# -s --cacerts myCA.pem -u msgUser1 -p wrongPassw0rd

We have now set up LDAP Authentication to go with our TLS secured communication. We’re making really progress! In the next installment we’ll talk about a different way of doing authentication: OAuth2.