55 lines
2.4 KiB
Markdown
55 lines
2.4 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.
|
|
|
|
## 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)
|