Thore CimbalandClaude Opus 5
8ca8a97a06
apo reads the wiki now. Checking every other configured user turned up the bigger finding: Authentik has a group wiki-zugang with four members, and Wiki.js does not honour it. Groups map by name, and the wiki only knows wiki-anwender and authentik Admins - so elbojoloco, clark and Boje hold membership that does nothing, while the name promises the opposite. Nobody noticed because none of them ever attempted a login; Wiki.js has exactly two OIDC users. The reason is a leftover: two Authentik applications share the display name "ThreadNet Wiki". The one carrying the wiki-zugang policy has no provider at all - an empty shell from the Docusaurus forward-auth era that ADR-0014 retired. The live wiki-js application carries no policy binding, so it is open to any authenticated user and the whole separation rests on a group assignment nobody looks for there. So the trap cuts both ways: granting wiki-zugang grants nothing, and the real application is ungated at its own layer. Acceptance now also covers retiring the dead shell, resolving wiki-zugang, and the two empty leftover groups. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
137 lines
6.3 KiB
Markdown
137 lines
6.3 KiB
Markdown
---
|
|
type: issue
|
|
id: "0103"
|
|
status: open
|
|
created: 2026-08-18
|
|
milestone: M1
|
|
priority: medium
|
|
projekt: gitops
|
|
related:
|
|
- "docs/issues/0049-wikijs-oidc-rollen-abschottung.md"
|
|
- "docs/adr/0014-wikijs-loest-docusaurus-ab.md"
|
|
gitlab_iid: "62"
|
|
---
|
|
# Wiki: Anmeldung ohne Gruppe endet stumm — `wiki-anwender` hat null Mitglieder
|
|
|
|
> Aufgefallen 2026-08-18, weil `@apo` nicht ins Wiki kam. Die Einzelfrage ist ein
|
|
> Handgriff; das Issue führt den Teil, der bleibt.
|
|
|
|
## Befund (gemessen am laufenden System)
|
|
|
|
`@apo` **meldet sich erfolgreich an** und landet in keiner Gruppe:
|
|
|
|
| Prüfung | Ergebnis |
|
|
|---|---|
|
|
| Wiki-Nutzer für apo | vorhanden (id 6), angelegt 2026-08-16, letzter Login 2026-08-18 17:21 |
|
|
| Identität belegt | OIDC-Subjekt `2fafe38b…` = apos `upstream_oauth_links`-Eintrag in MAS |
|
|
| Gruppen dieses Nutzers | **keine** |
|
|
| Gruppe `wiki-anwender` (id 4) | existiert, **0 Mitglieder** |
|
|
| Gruppe `authentik Admins` (id 3) | 1 Mitglied (sorB) |
|
|
|
|
Die Gruppen-Übernahme selbst funktioniert — sonst wäre sorB nicht automatisch in
|
|
`authentik Admins` gelandet. Es fehlt die Mitgliedschaft, sonst nichts.
|
|
|
|
## Warum daraus Stille wird
|
|
|
|
Drei bewusste Einzelentscheidungen ergeben zusammen eine Sackgasse:
|
|
|
|
1. `selfRegistration: True` auf der OIDC-Strategy — der erste Login **legt ein
|
|
Konto an**, ohne dass jemand etwas tun muss.
|
|
2. `autoEnrollGroups: []` — dieses Konto bekommt **keine** Gruppe.
|
|
3. `Guests` wurde per Konfig-Job auf `permissions: []`, `pageRules: []` gesetzt,
|
|
und die einzige Regel für `home` gilt nur für `wiki-anwender` (#0049).
|
|
|
|
Ergebnis: Für einen Nutzer ohne Gruppe greift **auf jedem Pfad** Default-Deny, die
|
|
Startseite eingeschlossen. Er sieht kein „du brauchst eine Freigabe", sondern nichts.
|
|
Betrieblich ist es genauso still: Bei der aktuellen Log-Stufe steht in den
|
|
Wiki-Logs nur der Git-Sync — ein Login ohne Gruppe hinterlässt keine Zeile, kein
|
|
Zähler, keine Meldung. Niemand erfährt, dass jemand vor der Tür stand.
|
|
|
|
**Das betrifft nicht nur apo.** `wiki-anwender` hat null Mitglieder: Das Wiki ist
|
|
derzeit faktisch Admin-only, und jeder Nicht-Admin, der es je versucht hat, hat
|
|
dasselbe erlebt.
|
|
|
|
Dieselbe Klasse wie der `mrtc`-Ausfall: alles grün, Dienst gesund, benutzen kann
|
|
es keiner — und nichts meldet es.
|
|
|
|
## Zu entscheiden
|
|
|
|
**Empfehlung: `autoEnrollGroups` auf `wiki-anwender` setzen** (eine Zeile in
|
|
`apps/production/wikijs-config.py`, der Job ist idempotent und re-runnable).
|
|
Begründung: Wer sich über Authentik anmelden kann, ist bereits kuratiert — der
|
|
Zugang setzt einen Einladungstoken voraus. Die Kuratierung findet dort statt, nicht
|
|
noch einmal im Wiki. `/anwender` ist ausdrücklich die Anwenderfläche, und `betrieb/*`
|
|
bleibt über Default-Deny weiterhin admin-only; die Abschottung aus #0049 bleibt also
|
|
erhalten, sie verschiebt nur ihre Grenze auf die Stelle, die sie wirklich trennt.
|
|
|
|
**Alternative, falls die Kuratierung pro Person gewollt ist:** Mitgliedschaft
|
|
bleibt Handarbeit in Authentik — dann muss aber die Sackgasse sprechen, sonst
|
|
wiederholt sich der Fall bei jedem neuen Nutzer.
|
|
|
|
Beides schließt sich nicht aus; die Rückmeldung ist auch bei Auto-Enrollment
|
|
sinnvoll, weil sie den Fall „Gruppe später entzogen" abdeckt.
|
|
|
|
## Acceptance
|
|
|
|
- Ein Nutzer ohne Sonderrechte, der sich neu anmeldet, **kommt an die Anwenderdoku
|
|
heran oder erfährt im Klartext, was ihm fehlt** — nachgewiesen an einem echten
|
|
Login, nicht an der Konfiguration.
|
|
- `betrieb/*` bleibt für ihn gesperrt (Gegenprobe, sonst ist die Abschottung
|
|
aufgeweicht statt verschoben).
|
|
- Der Fall „angemeldet, aber ohne Gruppe" ist **erkennbar**: mindestens eine
|
|
Logzeile oder ein Zähler, damit der nächste Fall nicht wieder erst auffällt,
|
|
wenn sich jemand beschwert.
|
|
- `@apo` kommt rein (die auslösende Frage — kein Ersatz für die Punkte oben).
|
|
|
|
## Sofortmaßnahme, unabhängig davon
|
|
|
|
apo in Authentik der Gruppe `wiki-anwender` hinzufügen; greift beim nächsten Login
|
|
automatisch, ohne Eingriff im Wiki. Das ist eine Rechtevergabe und liegt bei sorb.
|
|
|
|
## Nachtrag 2026-08-18 — die Kuratierung lief in die falsche Gruppe
|
|
|
|
apo ist inzwischen in `wiki-anwender` und liest (Login 17:31 nach der Freigabe).
|
|
Die Nachprüfung *aller* eingerichteten Nutzer hat aber einen größeren Fund ergeben.
|
|
|
|
**Authentik-Stand (gemessen über `ak shell`):**
|
|
|
|
| Nutzer | Gruppen | Wirkung im Wiki |
|
|
|---|---|---|
|
|
| sorB | `authentik Admins`, `wiki-zugang` | voll |
|
|
| apo | `wiki-anwender`, `wiki-zugang` | Leser ✓ |
|
|
| elbojoloco | nur `wiki-zugang` | **keine** |
|
|
| clark | nur `wiki-zugang` | **keine** |
|
|
| Boje | — | **keine** |
|
|
| lucky | — | **keine** |
|
|
|
|
Wiki.js bildet Gruppen **über den Namen** ab und kennt nur `wiki-anwender` und
|
|
`authentik Admins`. `wiki-zugang` (4 Mitglieder) zählt also nicht — obwohl der Name
|
|
das Gegenteil verspricht. Aufgefallen ist es nie, weil von den vier Betroffenen
|
|
noch niemand einen Login versucht hat: Wiki.js kennt genau zwei OIDC-Nutzer.
|
|
|
|
**Woher `wiki-zugang` kommt — zwei Anwendungen gleichen Namens:**
|
|
|
|
- `wiki` („ThreadNet Wiki") hat **keinen Provider** mehr — leere Hülle aus der
|
|
Docusaurus-/Forward-Auth-Zeit, mit ADR-0014 stillgelegt. **An ihr** hängt die
|
|
Policy-Bindung auf `wiki-zugang`.
|
|
- `wiki-js` („ThreadNet Wiki", identischer Anzeigename) ist die lebende Anwendung
|
|
— **ohne jede Policy-Bindung**, also für jeden authentifizierten Nutzer offen.
|
|
|
|
Die Folge ist eine Falle mit zwei Seiten: Wer jemanden zu `wiki-zugang` hinzufügt,
|
|
erteilt Rechte an einer toten Anwendung und wundert sich, dass nichts passiert.
|
|
Und die echte Anwendung steht auf ihrer Ebene offen — die gesamte Abschottung hängt
|
|
an einer Gruppenzuordnung, die dort niemand vermutet. `wiki-admin` und
|
|
`wiki-betrieb` liegen zusätzlich leer herum, Reste derselben Ablösung.
|
|
|
|
**Erweiterte Acceptance:**
|
|
|
|
- Es gibt **eine** erkennbare Wiki-Anwendung in Authentik. Die tote `wiki`-Hülle
|
|
ist entfernt oder eindeutig als stillgelegt benannt — zwei Kacheln mit demselben
|
|
Namen sind der Kern dieser Verwechslung.
|
|
- `wiki-zugang` ist aufgelöst oder mit `wiki-anwender` zusammengeführt; niemand
|
|
bleibt in einer Gruppe zurück, die nichts bewirkt.
|
|
- Leere Altgruppen (`wiki-admin`, `wiki-betrieb`) sind entfernt oder haben einen
|
|
benannten Zweck.
|
|
- Für die vier heute wirkungslos berechtigten Nutzer ist entschieden, wer davon
|
|
Zugang bekommt (`clark`/`lucky` sind laut #0074 ohnehin Testkonten zum Löschen).
|