Enterprise RBAC + SSO
SAML 2.0 Single Sign-On, SCIM 2.0 Provisioning, Custom Roles, IP-Allowlists und Data-Residency-Lock — die Org-Level-Identity-Story für regulierte Käufer.
Für Procurement- und Security-Teams, die Moonborn evaluieren, lautet die Frage meist „wie integriert ihr euch in unseren Identity-Stack?" Drei kanonische Antworten: SAML 2.0 Single Sign-On, SCIM 2.0 Provisioning und eine Role-Based-Access-Control-Matrix, die in Custom Roles erweitert werden kann.
Wann das passt
- Enterprise-IT stellt Moonborn neben ihren existierenden Identity-Provider (Okta, Azure AD, Google Workspace, OneLogin).
- Compliance-Teams, die belegbare User-Lifecycle-Kontrollen benötigen — Joiners, Movers, Leavers automatisch im Produkt reflektiert.
- Security-Teams, die netzwerkgebundenen API-Zugriff brauchen.
- Data-Residency-Anforderungen — Moonborn pinnt Daten beim Signup an eine US- oder EU-Region, danach gelockt.
Was mitkommt
| Capability | Tarif |
|---|---|
| Eingebaute Rollen (Owner, Admin, Editor, Viewer, API-only, Billing, Auditor) | Pro |
| SAML 2.0 SSO | Enterprise |
| SCIM 2.0 Provisioning | Enterprise |
| Custom Roles | Enterprise |
| IP-Allowlist (CIDR) | Enterprise |
| Data-Residency-Lock (US/EU) | Enterprise (beim Signup gesetzt) |
| Cross-Region-Read-Prevention | Enterprise |
| Long-Retention Audit-Log | Enterprise |
| 4-Augen-Approvals auf destruktive Aktionen | Enterprise |
Die Architektur
Identity ist Gateway-mediated. Jeder Request trägt einen Bearer-
Token — entweder ein Session-JWT (Cookie-gebunden, SAML-issued)
oder einen API-Key (sk_*-Prefix). Der Token löst am Gateway zu
einem (user, org, workspace)-Tuple auf. RBAC wird durchgesetzt,
bevor irgendein Use Case die Domain berührt.
Für SCIM treffen IdP-seitige Änderungen die /v1/auth/scim/v2/*-
Endpoints (RFC 7644) von Moonborn. User-Lifecycle bleibt
single-sourced in deinem IdP; Moonborn ist der Empfänger.
Rollen + Permissions-Matrix (eingebaut)
| Rolle | personas | chat | billing | config | webhooks | audit | members |
|---|---|---|---|---|---|---|---|
| Owner | RW | RW | RW | RW | RW | R | RW |
| Admin | RW | RW | RW | RW | RW | R | RW |
| Editor | RW | RW | — | R | R | — | — |
| Viewer | R | R | — | R | R | — | — |
| API-only | scoped | scoped | — | scoped | scoped | — | — |
| Billing | — | — | RW | — | — | — | — |
| Auditor | — | — | R | R | R | R | R |
Custom Roles (Enterprise) erlauben dir, die Matrix anders zu schneiden.
Audit-Log
Jede Membership-Änderung, Rollen-Änderung, Config-Edit und Persona- Mutation landet in einem immutablen, hash-chained Audit-Log. Default-Retention: 1 Jahr (Pro/Team), 7 Jahre (Enterprise). Pro Workspace innerhalb der Plan-Allowance tunbar.
GET /v1/audit/events gibt paginierte Events zurück, filterbar
nach Kategorie, Actor, Target und Zeitfenster. Der Log ist auch
für Compliance-Archivierung via POST /v1/audit/export (Team+)
exportierbar.
Data Residency
Beim Org-Signup wähle US oder EU. Alle persistenten Daten — Personas, Chat-Transcripts, Audit-Log, Embeddings — bleiben in dieser Region. Cross-Region-Reads sind an der Datenbank-Grenze geblockt.
Regions zu wechseln ist in-flight nicht unterstützt. Um zu migrieren, Daten exportieren, neue Region anlegen und importieren. ADR 0011 erklärt warum: In-Flight-Migration würde komplexe Consistency-Reasoning erfordern und das „Region ist eine Eigenschaft der Org"-Invariant der ADR brechen.
Was dieser Use Case NICHT ist
- Keine CIAM-Plattform. Moonborn verwaltet deine End-User nicht (die Leute, die deine Kunden bedienen). Die leben in deinem IdP.
- Kein Directory-Service. SCIM ist einseitig: IdP → Moonborn. Wir syncen nicht zurück.
- Kein Security-Audit-Tool. Der Audit-Log ist ein Record dessen, was passiert ist; SOC-2-style Continuous Monitoring lebt anderswo (Drata, Vanta, dein SIEM).
Tarif
Enterprise.
Weiter
- Setup-Walkthrough: Workspace + RBAC setup tutorial.
- Spezifische Guides: SSO / SAML setup, SCIM provisioning, RBAC role matrix.
- Compliance-Posture: Audit + compliance use case.