Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Enterprise overview

The Community Edition (edssa-server-ce) ships under BSL 1.1 with a strict feature subset documented in CE feature subset. Everything held back from CE lives in the Enterprise build of edssa-proxy + the operator panel + the sibling crates edssa-tenant, edssa-sso.

What’s in Enterprise

CapabilityCEEnterprise
Token widths64 only32 / 64 / 128 / 256
Fleet count1 per processunbounded
Multi-tenant hierarchy (Tenant / Organization / Fleet)✓ (Multi-tenant)
Per-tenant audit isolation (cryptographic + filesystem + RBAC)
SAML / OIDC SSO✓ (SSO)
Per-fleet + per-source-IP + per-(fleet, sub-ID) rate limiting✓ (Production hardening)
Tier-3 trace + Tier-4 Merkle audit
F-03 swarm, F-04 relay roles
F-06 EdSSA Orbit (orbit-coupled state advancement)
F-16 drift corrector
F-19 response-ID chain (Tier-3 replay)
F-22 schema-derived bytes
Hot-publish state mutation (Phase-2 ratchet)
Cooperative recovery (F-24/F-25)
ML-KEM onboarding (F-07)
Payload channel (F-26/F-27/F-28)
WebAuthn / SSO panel auth

Binary + crate layout

  • edssa-proxy — the Enterprise verifier. Same crate as the CE-substrate proxy, but built with default-features on edssa-core (the enterprise cargo umbrella) + the manifest’s Enterprise-shaped fields enabled.
  • edssa-panel — the Enterprise operator panel. WebAuthn auth
    • /tenants + /sso/* routes + the per-fleet plasticity / audit-tier / rate-limit edit flows.
  • edssa-tenant — multi-tenant hierarchy types (Tenant, Organization, FleetRef, TenantStore trait). Consumed by edssa-panel (RBAC, UI) + edssa-audit (per-tenant Merkle scope).
  • edssa-sso — SSO provider abstraction (AuthProvider trait, AuthProviderRegistry, flow types). Concrete samael
    • openidconnect impls land behind cargo features in customer-driven follow-up batches.
  • edssa-admin — operator CLI for on-box inspection (manifest dump, trigger registry, fleet detail, handshake apply).

Architectural calls worth knowing

  • CE / Enterprise share the engine. edssa-core’s hot path (verify_token, EdssaCore, EdssaRouter) is identical between the two builds — the differences are in which modules link in (the enterprise cargo feature gates relay, swarm, oracle, weaver, drift::MedianOf3) and which manifest fields are accepted at boot.
  • The validation gate is the load-bearing boundary, not the feature flag. CE’s edssa-server-ce validates incoming manifests at boot and rejects Enterprise-shaped fields with a clear error message + docs pointer; the feature flag is defence-in-depth (no Enterprise symbols are compiled into the CE binary either). Operators upgrading from CE to Enterprise change the binary, not the manifest format.
  • The same wire format works in both builds. CE clients + Enterprise clients are bit-for-bit interchangeable; the only difference is what the verifier does with the token after authenticating it (multi-fleet routing, per-tenant audit, rate-limit enforcement, Tier-3 response chain, etc).

Where to next

  • New to multi-tenant operations? Start with Multi-tenant.
  • Integrating SAML / OIDC for the operator panel? See SSO.
  • Tuning rate limits + observability? See Production hardening.
  • General operator concerns (deployment, seed rotation, observability surface) are still in the CE Operator runbook — most of it applies to Enterprise unchanged.