Enterprise RBAC + SSO
SAML 2.0 single sign-on, SCIM 2.0 provisioning, custom roles, IP allowlists, and data-residency lock — the org-level identity story for regulated buyers.
For procurement and security teams evaluating Moonborn, the question is usually "how do you integrate with our identity stack?" Three canonical answers: SAML 2.0 single sign-on, SCIM 2.0 provisioning, and a role-based access control matrix that can extend into custom roles.
When this fits
- Enterprise IT standing up Moonborn alongside their existing identity provider (Okta, Azure AD, Google Workspace, OneLogin).
- Compliance teams that require provable user lifecycle controls — joiners, movers, leavers automatically reflected in the product.
- Security teams that need network-bound API access.
- Data residency requirements — Moonborn pins data to a US or EU region at signup, locked thereafter.
What ships
| Capability | Tier |
|---|---|
| Built-in roles (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 (set at signup) |
| Cross-region read prevention | Enterprise |
| Long-retention audit log | Enterprise |
| 4-eyes approvals on destructive actions | Enterprise |
The architecture
Identity is gateway-mediated. Every request carries a bearer token —
either a session JWT (cookie-bound, SAML-issued) or an API key
(sk_* prefix). The token resolves to a (user, org, workspace)
tuple at the gateway. RBAC is enforced before any use-case touches
the domain.
For SCIM, IdP-side changes hit Moonborn's /v1/auth/scim/v2/*
endpoints (RFC 7644). User lifecycle stays single-sourced in your
IdP; Moonborn is the receiver.
Roles + permissions matrix (built-in)
| Role | 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) let you cut the matrix differently.
Audit log
Every membership change, role change, config edit, and persona mutation lands in an immutable, hash-chained audit log. Default retention: 1 year (Pro/Team), 7 years (Enterprise). Tunable per workspace within the plan's allowance.
GET /v1/audit/events returns paginated events, filterable by
category, actor, target, and time range. The log is also exportable
via POST /v1/audit/export (Team+) for compliance archival.
Data residency
At org signup, choose US or EU. All persistent data — personas, chat transcripts, audit log, embeddings — stays in that region. Cross- region reads are blocked at the database boundary.
Switching regions is not supported in-flight. To migrate, export data, sign up the new region, and import. ADR 0011 explains why: in-flight migration would require complex consistency reasoning and break the ADR's "region is a property of the org" invariant.
What this use case is NOT
- Not a CIAM platform. Moonborn doesn't manage your end users (the people your customers serve). Those live in your IdP.
- Not a directory service. SCIM is one-way: IdP → Moonborn. We don't sync back.
- Not a security audit tool. The audit log is a record of what happened; SOC 2-style continuous monitoring lives elsewhere (Drata, Vanta, your SIEM).
Tier
Enterprise.
Next
- Setup walkthrough: Workspace + RBAC setup tutorial.
- Specific guides: SSO / SAML setup, SCIM provisioning, RBAC role matrix.
- Compliance posture: Audit + compliance use case.