PPartnerDesk

03 — Rollen & Berechtigungen

Aktualisiert am 1. Juni 2026

03 — Rollen & Berechtigungen

PartnerDesk kennt vier verschiedene Personenkreise mit jeweils eigenen Login-Domains und Berechtigungen.

Übersicht

Rolle Login-URL Was kann man?
Plattform-Admin (PlatformUser) admin.partnerdesk.io Alle Tenants verwalten, Audit-Log einsehen, Webhook-Events replay’en, Failed Messages retry’en
Tenant-Admin (TenantUser) app.partnerdesk.io Eigenen Tenant verwalten: Partner, Kampagnen, Transaktionen, Auszahlungen, Akademie, Branding
Partner <slug>.partnerdesk.io Eigene Provisionen, Downline, Werbemittel, Akademie-Kurse
Hub-Account partnerdesk.io/hub Mehrere Partner-Identitäten bündeln (cross-tenant)

Rolle 1 — Plattform-Admin (PlatformUser)

Sichtbarkeit

Globale Sicht. Nicht an einen Tenant gebunden.

Aktionen

  • Tenants anlegen, suspendieren, reaktivieren.
  • Plan-Tier ändern.
  • Audit-Log durchsuchen.
  • Webhook-Events aller Tenants inspizieren und replay’en.
  • Failed-Messages retry’en oder discarden.
  • Plattform-weite Broadcasts an Tenant-Owner senden.
  • API-Docs einsehen.

Unter-Rollen

  • ROLE_PLATFORM_OWNER — kann alles, inkl. Anlage neuer Plattform-Admins.
  • ROLE_PLATFORM_ADMIN — operativ, aber kein User-Management auf Plattform-Ebene.

Anlage

Über die CLI: app:platform-user:create <email> <password> <role>. Kein Self-Signup — Plattform-Admins werden nur vom Plattform-Owner-Bestand angelegt.

Rolle 2 — Tenant-Admin (TenantUser)

Sichtbarkeit

Nur eigener Tenant. Kann andere Tenants nicht sehen.

Aktionen (Standard ROLE_ADMIN)

  • Partner anlegen, bearbeiten, suspendieren.
  • Kampagnen + Provisionsstufen pflegen.
  • Transaktionen einsehen, approven, rejecten.
  • Auszahlungen generieren, approven, als bezahlt markieren.
  • Notification-Templates pflegen.
  • Branding & Email-Whitelabel konfigurieren.
  • Legal-Pages bearbeiten.
  • Webhook-Event-Log einsehen (tenant-scoped).

Sonderrolle ROLE_OWNER

Tenant-Owner kann zusätzlich:

  • Weitere TenantUser anlegen.
  • Subscription verwalten (Stripe-Billing).
  • Tenant-Anonymisierung beantragen (DSGVO Art. 17).

Anlage

Drei Wege:

  • Self-Service-Signup auf partnerdesk.io/signup (legt automatisch den ersten Owner an).
  • Plattform-Admin legt im Superadmin-UI an.
  • CLI: app:tenant-user:create <tenant-slug> <email> <password>.

Rolle 3 — Partner

Sichtbarkeit

Nur eigene Daten + eigene direkte Downline.

Aktionen

  • Eigene Provisionen + Auszahlungen einsehen.
  • Tracking-Links und Werbemittel kopieren.
  • Eigene Landing-Page anlegen + pflegen.
  • Akademie-Kurse durchlaufen.
  • Profil + Bankdaten pflegen.
  • 2FA aktivieren.
  • Konto-Löschung beantragen (siehe 93 — DSGVO).

Anlage

Vier Wege:

  • Tenant-Admin legt im Admin-Portal an.
  • Self-Registration auf <slug>.partnerdesk.io/register (Status zunächst pending).
  • Invite-Flow: Admin sendet Mail mit Token-Link.
  • CLI (für Imports): siehe 20 — Partner anlegen.

Status-Lebenszyklus

pending → active → optional suspended → optional terminated → optional deletion_pending → anonymized (Daten weichen anonymen Werten).

Details: 21 — Partner-Status.

Rolle 4 — Hub-Account

Zweck

Ein Partner, der für mehrere Tenants aktiv ist, kann sich einen Hub-Account anlegen. Der Hub verknüpft alle Partner-Identitäten unter einer Email.

Sichtbarkeit

Cross-Tenant: kombinierte KPIs + getrennte Listen pro Tenant.

Aktionen

  • Hub-Login (partnerdesk.io/hub).
  • Bestehende Partner-Accounts „claimen" via Email-Verification.
  • Cross-Tenant-Dashboard (kumulierte Provisionen, einzelne Programme).

Anlage

  • Self-Service auf partnerdesk.io/hub/register.
  • Anschließend Claim-Wizard für jeden Partner-Account, den der Hub bündeln soll.

Details: 121 — Cross-Tenant-Hub.

Authentifizierung & Sicherheit

Alle vier Rollen haben:

  • JWT-Token-basierte Auth (LocalStorage im Browser).
  • Eigene Token-Keys pro Rolle — parallele Logins in verschiedenen Rollen sind möglich.
  • 2FA optional aktivierbar (Plattform-Admin und Tenant-Admin; bei Partner geplant).
  • Rate-Limiting auf allen Login-Endpoints (5 Versuche pro Minute).
  • Audit-Log: jeder Login (erfolgreich oder fehlgeschlagen) wird protokolliert.

Tenant-Boundary

Die wichtigste Sicherheits-Eigenschaft: kein Tenant-Admin kann jemals Daten eines anderen Tenants sehen oder verändern. Diese Garantie wird durch:

  • Die TenantResolver-Komponente (jeder Request kennt seinen Tenant).
  • Der TenantUserProvider (User wird tenant-scoped geladen).
  • Foreign-Key-Constraints (alle Domain-Entities haben tenant_id).
  • Repository-Methoden, die tenant_id immer im WHERE haben.

… auf vier Ebenen abgesichert. Plus: ein dediziertes Test-Set deckt jede API-Route gegen Cross-Tenant-Lookups ab.

Verwandte Kapitel

Technische Tiefen-Doku: ../001-initial-setup.md, ../005-campaign-management.md (TenantUserProvider), ../021-superadmin-cicd.md (PlatformUser), ../110-cross-tenant-hub.md