llldap

Important

You may be looking for lldap instead, a more mature solution with a different feature set.

Is your Lightweight Directory Access Protocol server too heavy and too cumbersome? If your lldap not light enough or are you looking for a solution which supports virtualhosts and multiple-value attributes such as mail aliases? llldap might be just for you!*

Warning

This is not production-ready yet.

Building

By default, building the binary expects to have the assets and templates folder in the same folder as the binary, as is useful during development. If you'd like to build a portable binary that embeds the assets and templates, you need to add the embed feature flag, for which you need to disable the default noembed feature:

cargo build --release --features embed,http --no-default-features
# My binary now contains everything and can be copied to a remote server
scp target/release/llldap ..........

Comparison to lldap

Compared to lldap, llldap:

• does not use an SQLite database, but simple text files
• does not use GraphQL to build an API, and therefore does not require custom logic in the client (JS/WASM)
• supports virtualhosts out-of-the-box
• supports mailalias with multiple values in search queries
• support listening on unix domain sockets (UDS) out-of-the-box

Design

Important

Most of these design decisions have not been implemented yet.

• different users can have the same username across different domains, so foo@bar.com is not the same user as foo@baz.com
• service accounts are separated from normal user accounts, and do not have an associated domain; they allow 3rd-party programs to connect via LDAP with special sets of permissions
• service groups are separated from normal user groups, and do not have an associated domain; they are meant to store permissions (eg. admins, or mail)
• aliases are supported, but remain associated with a user account forever (more details)
• TODO: should users be able to create custom groups/aliases? that sounds useful, but may need monitoring to prevent accidental/malicious abuse (such as registering comptabilité@ or legalteam@)

Potential future features

We may explore in the future:

• domain mapping (eg. .org/.fr/.onion)
• optional complete logging of all activity
• 2-factor auth
• Shamir's secret sharing social account recovery
• Permission to create invites on an account
• i18n domains (punycode)
• i18n user identifiers (TODO: check compatibility with other tools) see this IETF draft
• RTL languages
• hierarchical groups
• fine-grained permissions (RBAC)
• running with different async runtimes
• implying base DN from HTTP HOST header (to have auth.a.localhost and auth.b.localhost where users can login without adding the domain part)
• making the core logic reusable as a library for custom LDAP behavior
• per-user/domain data retention policies to keep logs of login attempts
• per-domain admins

License

GNU AGPL v3