Portal (Multi‑Tenant) – Setup

Ziel: Kunden loggen sich via Authentik ein und sehen danach nur ihren Mandanten. Mandanten laufen über IDs (z.B. tenant-123).

1) Authentik: App + Gruppen

• Lege eine Application an: Portal (z.B. Name: sasas-cloud-portal)
• Lege pro Mandant eine Gruppe an: portal_customer_tenant-123
• User werden genau einer Kunden-Gruppe zugeordnet
• Admin-Gruppe: portal_admin

2) Caddy: forward_auth (Konzept)

Damit /portal/ wirklich geschützt ist, braucht Caddy einen Authentik Outpost (Proxy Provider). Danach kann Caddy Requests zu Authentik schicken.

Caddy-Skizze (muss an eure Outpost-URL angepasst werden):

# Beispiel: /portal/ absichern
handle_path /portal/* {
  forward_auth https://sso.sasas.cloud {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name
  }
  root * /var/www/sasas.cloud
  file_server
}

Wichtig: Das ist der Rahmen. Wir müssen die echte Outpost-Route/Provider in Authentik sauber anlegen (sonst blockt’s alles oder lässt alles durch).

3) Mandanten-Zuordnung (v1 → v2)

• v1: Portal ist SSO-geschützt + zeigt statische Portal-Startseite (nur Struktur).
• v2: Live-Daten via Tactical RMM API. Sentinel mappt X-Authentik-Groups → Tenant-ID und fragt dann nur diesen Mandanten ab.

4) Tactical RMM API (nächster Step)

Wir bauen einen kleinen Portal-Backend-Service (Node) mit:

• API-Token pro Mandant oder Server-Token + Mandantenfilter
• Endpoints: /api/portal/me, /api/portal/devices, /api/portal/reports
• Strict: keine Tenant-ID aus Query akzeptieren – nur aus SSO-Claims/Groups ableiten