No description
  • Rust 89.5%
  • HTML 8.5%
  • CSS 2%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-09-21 17:13:38 +02:00
assets ux: Better responsive design (not great yet) 2026-09-21 16:20:55 +02:00
docs docs: Start design for aliases 2026-09-21 17:13:38 +02:00
src docs: More TODO 2026-09-21 16:21:18 +02:00
templates ux: Better responsive design (not great yet) 2026-09-21 16:20:55 +02:00
vendor/dn_escape feat: Implement LDAP bind/whoami 2026-09-01 21:18:19 +02:00
.gitignore feat: Initial accept loop 2026-09-01 15:27:28 +02:00
build.rs feat: Add embed and noembed feature flags for HTTP assets/templates 2026-09-08 17:24:10 +02:00
Cargo.lock feat: Redirect to requested URL after login 2026-09-20 18:13:59 +02:00
Cargo.toml feat: Redirect to requested URL after login 2026-09-20 18:13:59 +02:00
LICENSE feat: Initial accept loop 2026-09-01 15:27:28 +02:00
README.md docs: Start design for aliases 2026-09-21 17:13:38 +02:00

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.

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:

  • i18n domains (punycode)
  • i18n user identifiers (TODO: check compatibility with other tools)
  • 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