llldap/README.md

# 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.

## 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:

```shell
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](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:

- 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](https://datatracker.ietf.org/doc/html/draft-ietf-mailmaint-interoperable-addresses)
- 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)