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

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

## 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.