--- 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** — 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.