Files

T

Thore CimbalandClaude Opus 5 8ca8a97a06 docs(issues): #0103 - the curation went into a group that grants nothing

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>

2026-08-18 12:00:00 +00:00

6.3 KiB

Raw Blame History

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

type

status

created

milestone

priority

projekt

gitlab_iid

issue

0103

open

2026-08-18

medium

gitops

docs/issues/0049-wikijs-oidc-rollen-abschottung.md

docs/adr/0014-wikijs-loest-docusaurus-ab.md

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:

selfRegistration: True auf der OIDC-Strategy — der erste Login legt ein Konto an, ohne dass jemand etwas tun muss.
autoEnrollGroups: [] — dieses Konto bekommt keine Gruppe.
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).

6.3 KiB Raw Blame History

Wiki: Anmeldung ohne Gruppe endet stumm — wiki-anwender hat null Mitglieder