# llldap

> [!IMPORTANT]
> You may be looking for [lldap](https://github.com/lldap/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](https://github.com/lldap/lldap/issues/1196#issuecomment-3036760574) and [multiple-value attributes](https://github.com/lldap/lldap/issues/1133)
 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](docs/aliases.md))
- 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](LICENSE)