sorb/axion1337.chat-gitops
1
0
Fork 0
Code Issues Pull Requests Packages Projects 1 Releases 24 Wiki Activity

[MEDIUM] Gäste-Invite-Workflow per Bot (3-Tage-Accounts, Admin-Freischaltung, begrenzte Reaktivierung) #50

New Issue
Closed
opened 2026-08-01 09:22:20 +00:00 by sorb · 2 comments
sorb commented 2026-08-01 09:22:20 +00:00
Owner
Copy Link
Copy Source

Wunsch sorb (2026-08-01): definierter Prozess für sichere, temporäre Gast-Einladungen:

  1. Einladung: festgelegter Nutzerkreis schreibt den Bot an → Invite-Link wird generiert
  2. Initiales Limit: Gast-Account läuft nach 3 Tagen automatisch ab
  3. Permanente Freischaltung: nur durch aktive Admin-Prüfung; sonst bleibt der Account deaktiviert
  4. Fallback: ohne greifbaren Admin kann der einladende Kreis den Account über den Bot max. 2× um je 1 Tag reaktivieren, danach zwingend Admin

Architektur-Realitätscheck (Stack-Gegebenheiten)

  • Registrierung läuft in diesem Stack ausschließlich über Authentik (MAS-OIDC; die matrix-invitation-Flow-Infrastruktur mit Invitation-Stage existiert bereits aus Issue #7!). Der natürliche Invite-Link ist also ein Authentik-Invitation-Token (single-use, mit Ablauf) — kein Synapse-Registration-Token.
  • Draupnir ist ein Moderations-Bot ohne Invite-/Lifecycle-Funktion — er kann Policy-seitig flankieren (Gast-Raumrechte), aber die Link-Generierung + Ablauf-/Reaktivierungslogik braucht einen kleinen eigenen Bot (Machart wie @alerts/maintenance-notify: Stdlib, Matrix-API + Authentik-API + MAS/Authentik-Deaktivierung). Empfehlung: eigener @concierge-Bot statt Draupnir-Verbiegung; Draupnir-Integration als Stufe 2 (z. B. Gast-Label → eingeschränkte Räume).
  • Ablauf/Deaktivierung: Authentik-User-Attribut expires_at + periodischer Bot-Check (deaktiviert via Authentik-API → MAS-Sessions enden); Reaktivierungszähler als User-Attribut (max 2), Admin-Freischaltung = Attribut entfernen + Gruppe members.
  • Berechtigter Nutzerkreis: Matrix-Raum als ACL (wer im #einladungen-Raum ist, darf den Bot nutzen) — einfach und sichtbar.

Offene Designfragen (sorb)

  • Wer ist der „festgelegte Nutzerkreis" initial? Eigener Raum ok?
  • Soll die Admin-Prüfung im Matrix-Raum bestätigt werden (Reaktion/Kommando) oder in der Authentik-UI?
  • Namens-/Branding-Wunsch für den Bot?
**Wunsch sorb (2026-08-01):** definierter Prozess für sichere, temporäre Gast-Einladungen: 1. **Einladung:** festgelegter Nutzerkreis schreibt den Bot an → Invite-Link wird generiert 2. **Initiales Limit:** Gast-Account läuft nach **3 Tagen** automatisch ab 3. **Permanente Freischaltung:** nur durch aktive Admin-Prüfung; sonst bleibt der Account deaktiviert 4. **Fallback:** ohne greifbaren Admin kann der einladende Kreis den Account über den Bot **max. 2× um je 1 Tag** reaktivieren, danach zwingend Admin ## Architektur-Realitätscheck (Stack-Gegebenheiten) - Registrierung läuft in diesem Stack **ausschließlich über Authentik** (MAS-OIDC; die `matrix-invitation`-Flow-Infrastruktur mit Invitation-Stage existiert bereits aus Issue #7!). Der natürliche Invite-Link ist also ein **Authentik-Invitation-Token** (single-use, mit Ablauf) — kein Synapse-Registration-Token. - **Draupnir** ist ein Moderations-Bot ohne Invite-/Lifecycle-Funktion — er kann Policy-seitig flankieren (Gast-Raumrechte), aber die Link-Generierung + Ablauf-/Reaktivierungslogik braucht einen **kleinen eigenen Bot** (Machart wie @alerts/maintenance-notify: Stdlib, Matrix-API + Authentik-API + MAS/Authentik-Deaktivierung). Empfehlung: eigener `@concierge`-Bot statt Draupnir-Verbiegung; Draupnir-Integration als Stufe 2 (z. B. Gast-Label → eingeschränkte Räume). - **Ablauf/Deaktivierung:** Authentik-User-Attribut `expires_at` + periodischer Bot-Check (deaktiviert via Authentik-API → MAS-Sessions enden); Reaktivierungszähler als User-Attribut (max 2), Admin-Freischaltung = Attribut entfernen + Gruppe `members`. - **Berechtigter Nutzerkreis:** Matrix-Raum als ACL (wer im `#einladungen`-Raum ist, darf den Bot nutzen) — einfach und sichtbar. ## Offene Designfragen (sorb) - Wer ist der „festgelegte Nutzerkreis" initial? Eigener Raum ok? - Soll die Admin-Prüfung im Matrix-Raum bestätigt werden (Reaktion/Kommando) oder in der Authentik-UI? - Namens-/Branding-Wunsch für den Bot?
sorb commented 2026-08-01 11:29:49 +00:00
Author
Owner
Copy Link
Copy Source

Design festgezurrt (2026-08-01, sorb):

  1. Berechtigung = Authentik-Gruppe ∧ Matrix-Raum („Kontrolle + Transparenz"): Autoritativ ist die Mitgliedschaft in einer Authentik-Gruppe (z. B. invite-berechtigt); der Bot nimmt Kommandos ausschließlich im (invite-only) Einladungsraum an und prüft bei jedem Kommando beides. Der Raum macht sichtbar, wer einladen darf und woher ein Gast kommt (jede Einladung = nachlesbarer Raumeintrag „X hat Link für Gast Y erzeugt").
  2. Admin-Freischaltung im Matrix-Raum: Bot postet jeden registrierten Gast in den Raum, Admin bestätigt per Kommando (z. B. !freischalten @gast) — auditierbar im Verlauf, mobil möglich.
  3. Bot-Name: @concierge:axion1337.chat (Anlage per mas-cli wie @alerts, eigener Token).

Damit ist die Architektur vollständig: Authentik-Invitation-Token (Ablauf 3 Tage) → Gast registriert → Bot setzt expires_at-Attribut + postet in den Raum → periodischer Check deaktiviert abgelaufene Gäste → Reaktivierung max. 2×1 Tag über Bot-Kommando (Zähler als Attribut) → Admin-Freischaltung entfernt Ablauf + hebt in Mitglieder-Gruppe. Umsetzung als eigene Session, Machart wie die bestehenden Stdlib-Bots.

**Design festgezurrt (2026-08-01, sorb):** 1. **Berechtigung = Authentik-Gruppe ∧ Matrix-Raum** („Kontrolle + Transparenz"): Autoritativ ist die Mitgliedschaft in einer Authentik-Gruppe (z. B. `invite-berechtigt`); der Bot nimmt Kommandos ausschließlich im (invite-only) Einladungsraum an und prüft bei jedem Kommando beides. Der Raum macht sichtbar, *wer* einladen darf und *woher* ein Gast kommt (jede Einladung = nachlesbarer Raumeintrag „X hat Link für Gast Y erzeugt"). 2. **Admin-Freischaltung im Matrix-Raum**: Bot postet jeden registrierten Gast in den Raum, Admin bestätigt per Kommando (z. B. `!freischalten @gast`) — auditierbar im Verlauf, mobil möglich. 3. **Bot-Name: `@concierge:axion1337.chat`** (Anlage per mas-cli wie @alerts, eigener Token). Damit ist die Architektur vollständig: Authentik-Invitation-Token (Ablauf 3 Tage) → Gast registriert → Bot setzt `expires_at`-Attribut + postet in den Raum → periodischer Check deaktiviert abgelaufene Gäste → Reaktivierung max. 2×1 Tag über Bot-Kommando (Zähler als Attribut) → Admin-Freischaltung entfernt Ablauf + hebt in Mitglieder-Gruppe. Umsetzung als eigene Session, Machart wie die bestehenden Stdlib-Bots.
sorb commented 2026-08-01 14:26:15 +00:00
Author
Owner
Copy Link
Copy Source

Migriert nach git.lab: axion1337.chat/axion1337.chat-gitops#48 (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.

**Migriert nach git.lab**: [axion1337.chat/axion1337.chat-gitops#48](https://git.lab/axion1337.chat/axion1337.chat-gitops/-/issues/48) (nur im Lab bzw. via VPN erreichbar — das Lab ist seit 2026-08-01 die Quelle der Wahrheit, siehe gitops#48). Weiterarbeit dort; dieses Gitea-Issue bleibt als Verweis stehen.
sorb closed this issue 2026-08-01 14:26:15 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area:authentik
Authentik Identity Provider
 area:database
Database and backups
 area:element
Element and UI
 area:infrastructure
K3S and infrastructure
 area:security
Security hardening
 priority:critical
Critical - This week
 priority:high
High - 1-2 weeks
 priority:low
Low - nice to have
 priority:medium
Medium - ~1 month
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
sorb (ScrublordMcBad)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sorb/axion1337.chat-gitops#50