64 lines
2.7 KiB
Markdown
64 lines
2.7 KiB
Markdown
# Authentik — Lite Alternative: GLAuth
|
|
|
|
This is a short note about a deliberately-smaller IdP we considered for the
|
|
Phase 09 #81 setup but did **not** ship. It's documented here so the choice
|
|
is reversible later if the operational profile changes.
|
|
|
|
## Recommendation
|
|
|
|
**Use Authentik for staging + prod** (the chosen approach — see
|
|
`docs/operations/authentik-setup.md`). It supports MFA-TOTP enforcement,
|
|
OIDC + SAML + SCIM, declarative blueprints, brand-flows, a real web UI,
|
|
and is actively maintained.
|
|
|
|
**Consider GLAuth ONLY if** all of these apply:
|
|
|
|
- You only need **LDAP** (no OIDC, no SAML, no MFA enforcement at the IdP
|
|
layer).
|
|
- You are running on a VM with **less than 1 GB RAM free** for the whole IdP
|
|
stack (Authentik server+worker+postgres+redis needs ~1.5-2 GB).
|
|
- You are comfortable managing groups + users via YAML files + restart
|
|
rather than a UI.
|
|
- You don't need a self-service password reset, email-stage flows, brand
|
|
customisation, audit log UI, or invitation flows.
|
|
|
|
For our boilerplate (DSGVO, admin SSO, MFA pflicht, OIDC for the admin
|
|
panel, eventual customer-tenant-SSO) — **none** of those conditions apply.
|
|
|
|
## GLAuth profile (for reference)
|
|
|
|
- **Project:** <https://github.com/glauth/glauth>
|
|
- **Footprint:** single Go binary, ~25 MB image, ~15-50 MB RAM resident
|
|
- **Storage:** file-backed config (`config.toml` with users + groups inline)
|
|
OR a SQL backend for larger directories
|
|
- **Protocols:** LDAP (LDAPv3) only; some optional plugins for plain HTTP
|
|
password verification
|
|
- **Auth:** username + password (with bcrypt / SHA / OTP via plugin); NO
|
|
built-in OIDC, NO SAML, NO SCIM
|
|
- **MFA:** TOTP via plugin only; not enforceable by group/policy in the
|
|
same way Authentik does it
|
|
- **Audit:** stdout logs only; no event-bus
|
|
- **License:** MIT
|
|
- **Maintenance status (2026-05):** active, but small community; releases
|
|
every 2-3 months
|
|
|
|
## If we ever switch
|
|
|
|
The migration path from Authentik to GLAuth would be **manual**:
|
|
|
|
1. Export users + groups from Authentik via the API
|
|
(`/api/v3/core/users/`, `/api/v3/core/groups/`).
|
|
2. Translate into GLAuth's `config.toml` schema (users + groups + LDAP
|
|
attributes). Passwords are NOT exportable — every user must reset their
|
|
password on the new IdP.
|
|
3. Adapt every consuming app: the admin panel (#82) would need to swap its
|
|
OIDC client for an LDAP-bind code path. There is **no** OIDC bridge in
|
|
GLAuth.
|
|
4. Lose: MFA enforcement, audit-log UI, brand-flow customisation, the
|
|
declarative-blueprint workflow.
|
|
|
|
Realistically: **don't switch**. If Authentik's footprint genuinely becomes
|
|
the bottleneck (e.g. Hetzner-CX21 with 4 GB RAM is too small), the better
|
|
move is to give Authentik its own VM (see Section 8 of
|
|
`docs/operations/authentik-setup.md`) rather than swap the IdP.
|