gandc/lldap
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: update architecture.md

Browse Source
This commit is contained in:
Valentin Tolmer 2024-11-19 22:06:15 +01:00 committed by nitnelave
parent fea2ed5b79
commit c47be779a3
1 changed files with 13 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
docs/architecture.md
View File

@ -14,15 +14,14 @@ Backend:
is defined in `schema.graphql`. is defined in `schema.graphql`.
* The static frontend files are served by this port too. * The static frontend files are served by this port too.
Note that secure protocols (LDAPS, HTTPS) are currently not supported. This can Note that HTTPS is currently not supported. This can be worked around by using
be worked around by using a reverse proxy in front of the server (for the HTTP a reverse proxy in front of the server (for the HTTP API) that wraps/unwraps
API) that wraps/unwraps the HTTPS messages, or only open the service to the HTTPS messages. LDAPS is supported.
localhost or other trusted docker containers (for the LDAP API).
Frontend: Frontend:
* User management UI. * User management UI.
* Written in Rust compiled to WASM as an SPA with the Yew library. * Written in Rust compiled to WASM as an SPA with the Yew library.
* Based on components, with a React-like organization. * Based on components, with a React-like framework.
Data storage: Data storage:
* The data (users, groups, memberships, active JWTs, ...) is stored in SQL. * The data (users, groups, memberships, active JWTs, ...) is stored in SQL.
@ -50,19 +49,19 @@ Data storage:
Authentication is done via the OPAQUE protocol, meaning that the passwords are Authentication is done via the OPAQUE protocol, meaning that the passwords are
never sent to the server, but instead the client proves that they know the never sent to the server, but instead the client proves that they know the
correct password (zero-knowledge proof). This is likely overkill, especially correct password (zero-knowledge proof). This is likely overkill, especially
considered that the LDAP interface requires sending the password to the server, considered that the LDAP interface requires sending the password in cleartext
but it's one less potential flaw (especially since the LDAP interface can be to the server, but it's one less potential flaw (especially since the LDAP
restricted to an internal docker-only network while the web app is exposed to interface can be restricted to an internal docker-only network while the web
the Internet). app is exposed to the Internet).
OPAQUE's "passwords" (user-specific blobs of data that can only be used in a OPAQUE's "passwords" (user-specific blobs of data that can only be used in a
zero-knowledge proof that the password is correct) are hashed using Argon2, the zero-knowledge proof that the password is correct) are hashed using Argon2, the
state of the art in terms of password storage. They are hashed using a secret state of the art in terms of password storage. They are hashed using a secret
provided in the configuration (which can be given as environment variable or provided in the configuration (which can be given as environment variable,
command line argument as well): this should be kept secret and shouldn't change command line argument or a file as well): this should be kept secret and
(it would invalidate all passwords). Note that even if it was compromised, the shouldn't change (it would invalidate all passwords). Note that even if it was
attacker wouldn't be able to decrypt the passwords without running an expensive compromised, the attacker wouldn't be able to decrypt the passwords without
brute-force search independently for each password. running an expensive brute-force search independently for each password.
### JWTs and refresh tokens ### JWTs and refresh tokens