@cepharum/ldap-bridge

ldap-bridge

remotely backed LDAP authentication

License

MIT

About

This package implements an LDAP service suitable for authenticating users. It is translating incoming requests for binding as a user into authentication requests against configurable backend services such as POP3.

Example

Using this service, you can set up an LDAP-aware service such as Jitsi or Mattermost for users authenticating against the POP3 of your local MTA.

Security

In production mode the service requires encrypted connections with its clients as well as with backend services. Due to its nature it is forwarding any password provided by a client to related backend service. It isn't storing passwords. It isn't caching any result either. The service is working stateless.

As a beneficial side effect this results in this service's horizontal scalability.

To conclude, from a user's point of view this tool relies on a security issue as soon as you authenticate against backends you don't manage. This is due to the possibility of reading/tracking sensitive information meant to be shared by your user and the remote backend, only.

Setup

In a locally created folder run:

npm install -g @cepharum/ldap-bridge

Create configuration file config.js in current folder with content from distributed template file. Review the content and adjust it according to your needs.

Eventually start the service with:

npx ldap-bridge

Docker Support

The latest version is available as a docker image named registry.gitlab.com/cepharum-foss/ldap-bridge, too.

On first run this image is writing configuration template into mounted volume for review.

mkdir -p data
docker run -it --rm -v $(pwd)/data:/config registry.gitlab.com/cepharum-foss/ldap-bridge

After adjusting the configuration in data/config.js you can start the container with:

docker run -d --rm -p 636:636 -v $(pwd)/data:/config registry.gitlab.com/cepharum-foss/ldap-bridge

Logging

The service is logging to the console using debug. Thus, you can use DEBUG environment variable to adjust log levels. In docker image this defaults to *:alter,*:error,*:warn,*:info.

Encryption Required

In a production setup the service requires LDAP-side and backends to communicate over encrypted connections, only. You need to set NODE_ENV environment variable to development to work with non-encrypted LDAP server locally.

Attribute Qualification

When delivering LDAP entries as results of a search query those results may be qualified depending on a found user's mail address. It supports the following mail address formats resulting in additional LDAP attribute values for givenName, sn (for surname) and objectclass returned:

[e-mail]
[e-mail]
[e-mail]
[e-mail]

Either given name and the surname are converted to have leading capitals. Dashes are supported in those parts of address as well. Multiple given names separated by period in mail address are provided space-separated in resulting givenName attribute.

For example, the mail address

[e-mail]

results in LDAP entry

dn: uid=ann-mary.jane.miller-smith_admin,dc=foo,dc=com
objectclass: top
objectclass: user
objectclass: admin
uid: ann-mary.jane.miller-smith_admin
givenName: Ann-Mary Jane
sn: Miller-Smith

Fuzzy Queries

Sub-Addressing in LDAP Searches

When searching for a user by mail address its sub-addressing part is ignored. So, searching for

[e-mail]

results in

dn: uid=john.doe,dc=foo,dc=com
objectclass: top
objectclass: user
uid: john.doe
givenName: John
sn: Doe

The +office sub-address is omitted.

Additional RDNs in Bind DN

Any additional RDN is ignored on binding as a given user. The following bind DNs result in identical authentication requests against some matching backend:

uid=john.doe,dc=foo,dc=com
uid=john.doe,ou=people,dc=foo,dc=com
uid=john.doe,ou=staff,ou=people,dc=foo,dc=com

In either case the assumed user is described as:

{
    "mailbox": "john.doe",
    "domain": "foo.com",
    "address": "[e-mail]"
}