Files
management/docs/issues/0049-wikijs-oidc-rollen-abschottung.md
T

40 lines
1.5 KiB
Markdown
Raw Normal View History

---
type: issue
id: "0049"
status: open
created: 2026-08-12
milestone: M4
priority: medium
area: security
related: [docs/adr/0014-wikijs-loest-docusaurus-ab.md, docs/issues/0048-wikijs-in-der-suite-deployen.md]
---
# 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 `/betrieb` nicht (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.