Thore Cimbal
875e6d38d4
wiki.axion1337.chat (public, Let's-Encrypt TLS, native Authentik-OIDC login, no forward-auth) added to #0048 (ingress/cert pattern) and #0049 (redirect URI, same URL for user and admin, role decides). Kept out of ADR-0014 deliberately: accepted ADRs are not edited, and the hostname is a deployment detail, not a new decision.
1.5 KiB
1.5 KiB
type, id, status, created, milestone, priority, area, related
| type | id | status | created | milestone | priority | area | related | ||
|---|---|---|---|---|---|---|---|---|---|
| issue | 0049 | open | 2026-08-12 | M4 | medium | security |
|
Wiki.js: Authentik-OIDC + Rollen und Abschottung
Problem / Motivation
Der Kern der Wiki.js-Entscheidung (ADR-0014): Zugang und Sichtbarkeit nach Authentik-Gruppe, was Docusaurus nicht konnte.
Acceptance
- Authentik-OIDC als Login-Provider in Wiki.js (Gruppen-Claim gemappt) —
nativer Wiki.js-Login, kein Forward-Auth. Authentik-Provider mit Redirect-URI
https://wiki.axion1337.chat/login/<providerKey>/callback; Anwender und Admin rufen dieselbe URL auf, die Rolle entscheidet über Sicht/Bearbeiten. - Rollen über Gruppen:
- Admins: schreiben (read+write) Betriebs- und Anwenderhandbücher.
- Normale Nutzer: nur lesen — kein Schreiben.
- Abschottung: Anwender sehen die Betriebsdoku nicht (Pfad-/Seiten-Regeln
pro Gruppe,
/betrieb/*nur für die Betriebs-Gruppe). Betrieb darf Anwenderdoku lesen. - Verifiziert: Anwender-Konto sieht
/betriebnicht (nicht 403 mit sichtbarem Link, sondern gar nicht in Navigation/Suche); Nicht-Admin kann nichts editieren; Admin kann beides bearbeiten.
Notes
⚠️ Braucht die konkreten Authentik-Gruppen von sorb: welche Gruppe = Betrieb,
welche = Anwender, welche = Admin (Vorschlag: authentik Admins schreibt,
wiki-betrieb liest Betrieb+Anwender, wiki-anwender liest nur Anwender). Zugangs-
/Gruppenvergabe macht sorb selbst.