management/docs/issues/0103-wiki-zugang-ohne-gruppe-endet-stumm.md

type, id, status, created, milestone, priority, projekt, related, gitlab_iid

type	id	status	created	milestone	priority	projekt	related	gitlab_iid
issue	0103	open	2026-08-18	M1	medium	gitops	docs/issues/0049-wikijs-oidc-rollen-abschottung.md docs/adr/0014-wikijs-loest-docusaurus-ab.md	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 — inzwischen freigegeben, s. u.
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).

Freigaben bisher (Entscheidung sorb): apo und elbojoloco sind in wiki-anwender; damit lesen beide /anwender und die Startseite, betrieb/* bleibt gesperrt. Wirksam wird das jeweils beim nächsten Login — der Gruppen-Claim entsteht bei der Anmeldung, nicht laufend. elbojoloco hat sich noch nie am Wiki angemeldet; das Konto wird beim ersten Login angelegt und dabei zugeordnet.

Weiterhin ohne Wirkung: Boje (keine Gruppe) sowie clark und lucky (Testkonten, laut #0074 zum Löschen vorgesehen). Über Boje ist noch nicht entschieden. Solange die Punkte oben offen sind, bleibt für diese Konten der stumme Fall bestehen — das ist der Grund, warum dieses Issue nicht mit den Freigaben erledigt ist.

Umgesetzt 2026-08-19 — Auto-Enrollment aktiv

Entscheidung sorb, und sie stand schon in #0049: normale Authentik-Nutzer lesen die Anwenderdoku, Admins sind Admins („Betrieb = Admin"). Das Rollenmodell war umgesetzt, der Weg hinein nicht — deshalb dieser Fall.

autoEnrollGroups der OIDC-Strategy zeigt jetzt auf wiki-anwender (gitops:apps/production/wikijs-config.py, Commit dfb88a3). Der Konfig-Job wurde neu angestoßen (Job löschen → Flux legt ihn an, wie im Dateikopf beschrieben) und meldet: Auto-Enrollment in wiki-anwender, id 4.

In der laufenden Datenbank gegengeprüft, nicht am Logtext:

OIDC-Strategy  selfRegistration=t  autoEnrollGroups={"v":[4]}    # 4 = wiki-anwender
local          selfRegistration=f  autoEnrollGroups={"v":[]}     # Break-Glass, unverändert

Admins bleiben Handarbeit in Authentik: Mitgliedschaft in authentik Admins kommt über den groups-Claim und wird von dieser Grundausstattung nicht berührt. betrieb/* behält sein Default-Deny — die in #0049 end-to-end verifizierte Abschottung gilt unverändert, sie greift nur nicht mehr gegen Leute, die gar nicht erst hereingelassen wurden.

Der Skript-Teil bricht ab, wenn wiki-anwender fehlt, statt in eine leere Gruppe zu enrollen — das wäre genau der Fehler, den dieses Issue beschreibt.

Offen bleibt der Aufräumteil: die tote Authentik-Anwendung wiki ohne Provider und die Gruppe wiki-zugang (4 Mitglieder), die Rechte an ihr verteilt. Beides fasse ich erst auf Zuruf an, weil es Authentik-Konfiguration ist.