docs: update architecture.md
Some checks failed
Docker Static / pre_job (push) Has been cancelled
Rust / pre_job (push) Has been cancelled
Docker Static / build-ui (push) Has been cancelled
Docker Static / build-bin (aarch64-unknown-linux-musl) (push) Has been cancelled
Docker Static / build-bin (armv7-unknown-linux-musleabihf) (push) Has been cancelled
Docker Static / build-bin (x86_64-unknown-linux-musl) (push) Has been cancelled
Docker Static / LLDAP database init test (push) Has been cancelled
Docker Static / LLDAP database migration test (push) Has been cancelled
Docker Static / Build Docker image (push) Has been cancelled
Docker Static / Create release artifacts (push) Has been cancelled
Rust / cargo test (push) Has been cancelled
Rust / cargo clippy (push) Has been cancelled
Rust / cargo fmt (push) Has been cancelled
Rust / Code coverage (push) Has been cancelled

This commit is contained in:
Valentin Tolmer 2024-11-19 22:06:15 +01:00 committed by nitnelave
parent fea2ed5b79
commit c47be779a3

View file

@ -14,15 +14,14 @@ Backend:
is defined in `schema.graphql`.
* The static frontend files are served by this port too.
Note that secure protocols (LDAPS, HTTPS) are currently not supported. This can
be worked around by using a reverse proxy in front of the server (for the HTTP
API) that wraps/unwraps the HTTPS messages, or only open the service to
localhost or other trusted docker containers (for the LDAP API).
Note that HTTPS is currently not supported. This can be worked around by using
a reverse proxy in front of the server (for the HTTP API) that wraps/unwraps
the HTTPS messages. LDAPS is supported.
Frontend:
* User management UI.
* 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:
* 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
never sent to the server, but instead the client proves that they know the
correct password (zero-knowledge proof). This is likely overkill, especially
considered that the LDAP interface requires sending the password to the server,
but it's one less potential flaw (especially since the LDAP interface can be
restricted to an internal docker-only network while the web app is exposed to
the Internet).
considered that the LDAP interface requires sending the password in cleartext
to the server, but it's one less potential flaw (especially since the LDAP
interface can be restricted to an internal docker-only network while the web
app is exposed to the Internet).
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
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
command line argument as well): this should be kept secret and shouldn't change
(it would invalidate all passwords). Note that even if it was compromised, the
attacker wouldn't be able to decrypt the passwords without running an expensive
brute-force search independently for each password.
provided in the configuration (which can be given as environment variable,
command line argument or a file as well): this should be kept secret and
shouldn't change (it would invalidate all passwords). Note that even if it was
compromised, the attacker wouldn't be able to decrypt the passwords without
running an expensive brute-force search independently for each password.
### JWTs and refresh tokens