70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
# 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)
|