How do we enable SAML SSO and RBAC in Inngest Enterprise, and what’s the onboarding process?

Security-sensitive teams usually hit the same two questions first: how do we turn on SAML SSO so access is centralized, and how do we control who can do what once they’re in? In Inngest Enterprise, that means configuring SAML SSO and role-based access control (RBAC) as part of a guided onboarding process rather than bolting them on later.

This guide walks through how to enable SAML SSO and RBAC in Inngest Enterprise and what to expect from the onboarding process end‑to‑end.

Note: Exact UI labels and flows can evolve over time. Your Inngest account team will share the latest Enterprise onboarding checklist when you sign.

---

Quick Answer: How SAML SSO & RBAC Work in Inngest Enterprise

At a high level:

• SAML SSO: Inngest Enterprise integrates with your identity provider (IdP) via SAML 2.0. Your IdP becomes the single source of truth for authentication and, optionally, group/role assignment.
• RBAC: Inngest Enterprise exposes organization- and workspace-level roles so you can separate who can manage billing and security vs. who can ship and operate workflows, agents, and Durable Endpoints.
• Onboarding: You don’t configure this alone. Enterprise onboarding is a structured process: discovery → SSO + SCIM/SAML mapping → RBAC design → rollout and validation.

The rest of this article gets specific about how to enable each piece and what the onboarding lifecycle looks like.

---

Why SAML SSO and RBAC Matter for Inngest Enterprise

Inngest is where your workflows, agents, endpoints, and background jobs actually execute. That comes with real operational power: teams can query, cancel, or replay thousands of runs; tweak flow control for multi-tenant workloads; and configure integrations that touch production data.

For Enterprise customers, that power needs guardrails:

• Centralized authentication via SAML SSO means:
  • Deprovisioning happens once in your IdP, not after you remember to remove someone from Inngest.
  • Sign-in flows are consistent with the rest of your stack (MFA, device trust, risk-based access).
• Fine-grained authorization via RBAC means:
  • Only the right engineers can deploy new workflows or change concurrency keys.
  • SREs and platform teams can debug and replay runs without being able to change billing or organization-wide settings.
  • Audit teams can prove who has access to what—backed by SOC 2 Type II controls and Inngest’s built-in observability.

---

SAML SSO in Inngest Enterprise: How It Works

Inngest Enterprise supports SAML 2.0-based SSO with popular identity providers such as Okta, Azure AD, Google Workspace, and other SAML-compliant IdPs. The model is standard:

• Your users authenticate with your IdP.
• The IdP issues a SAML assertion to Inngest.
• Inngest validates the assertion and creates/links the user in your organization according to configured rules.

What You Configure in Your IdP

You’ll typically set up an “Inngest” application in your IdP with:

• Entity ID / Audience URI: Provided by Inngest as part of your Enterprise setup.
• Assertion Consumer Service (ACS) URL: The callback URL where your IdP sends SAML assertions.
• NameID: Usually the user’s email address.
• Attributes / Claims (recommended):
  • email
  • given_name
  • family_name
  • Optional: groups or a custom attribute that can map to Inngest roles or workspaces.

Your Inngest account team will provide the exact values for Entity ID and ACS URL and confirm which attributes to send.

What You Configure in Inngest

On the Inngest side, Enterprise configuration typically includes:

• IdP metadata:
  • IdP SSO URL
  • IdP Entity ID
  • X.509 certificate for signature validation
• SSO enforcement:
  • Whether SSO is required for all organization members.
  • Whether password-based logins are disabled for your org.
• Attribute mapping:
  • Which SAML attributes map to email and name.
  • Optional mapping from groups (or another attribute) to Inngest roles.

Once this is in place, logging in via “Continue with SSO” on your Inngest domain will redirect users to your IdP, and successful authentication will create or link their account in your organization based on the assertion.

---

RBAC in Inngest Enterprise: Roles and Permissions

SAML SSO answers “who are you?” RBAC answers “what can you do once you’re in?”

Inngest Enterprise RBAC is designed around clear separation of concerns: organization-level control for security and billing, and workspace-level control for day‑to‑day workflow operations.

Common Role Layers

Exact role names and capabilities depend on your Enterprise plan, but they generally break down as:

• Organization-level roles
  • Manage SAML SSO and security configuration.
  • Configure billing, plans, and global settings like trace retention.
  • Create and manage workspaces.
• Workspace-level roles
  • Manage Inngest Functions and deployments for that workspace.
  • Configure Flow Control (concurrency keys, throttling, prioritization) for specific workflows or tenants.
  • View and operate runs via Traces, Replay, and Bulk Cancellation.
  • Manage environment-level configuration (e.g., environment variables, secrets) within that workspace.

Typical Role Patterns

Most Inngest Enterprise customers end up with a pattern like:

• Org Admin / Security Admin
  • Owns SAML SSO, SCIM (if enabled), and overall access policy.
  • Usually a platform, security, or IT admin group.
• Platform / SRE
  • Workspace-level admin; can deploy new workflows, tweak Flow Control, and operate runs.
  • Can query, cancel, or replay workflows but does not manage billing.
• Developer
  • Can contribute workflows and inspect runs in specific workspaces.
  • Limited access to critical organization-level settings.
• Read-only / Observer
  • Can view Traces, structured logs, and run details for debugging and audits.
  • Cannot deploy or modify functions.

Your Inngest account team will work with you to map these roles to your team structure and to IdP groups where possible.

---

How SAML SSO and RBAC Work Together

The ideal Enterprise posture is:

1. Authentication via SAML SSO
   Users log in using your IdP. Inngest trusts your IdP to confirm identity and, optionally, group membership.

2. Authorization via RBAC
   Inngest maps each user to:

   • An organization-level role (e.g., Org Admin, Member).
   • One or more workspace-level roles (e.g., Admin in prod, Read-only in shared).

3. Optional group-based assignment
   If you send group attributes in SAML assertions, you can:

   • Auto-assign org roles based on security or platform groups.
   • Auto-grant workspace access for specific teams, reducing manual user management.

This keeps your access model centralized while still giving fine-grained control over who can deploy or operate high-impact workflows.

---

Enterprise Onboarding: Phase-by-Phase

Enabling SAML SSO and RBAC is part of the broader Inngest Enterprise onboarding, not a separate project. Here’s how the process typically unfolds.

Phase 1: Discovery & Design

Goal: Align on your security requirements and access model before you touch production.

You’ll cover:

• Security posture
  • SAML SSO requirements (e.g., enforced for all users).
  • Any SCIM or Just-In-Time (JIT) provisioning expectations.
  • Compliance requirements (SOC 2 Type II, HIPAA BAA, data locality).
• Org structure
  • How many environments/workspaces (e.g., dev, staging, prod).
  • Which teams will manage Inngest (platform, SRE, feature teams).
• Access patterns
  • Who needs org-level control?
  • Which teams need workspace admin vs. read-only roles?
  • Existing IdP group structure you’d like to reuse.

Output from this phase is usually a short “access design doc” with:

• Initial role definitions.
• Workspace layout (e.g., org-dev, org-staging, org-prod).
• Proposed mapping from IdP groups → Inngest roles.

Phase 2: SAML SSO Setup & Testing

Goal: Configure SSO in a low-risk environment and test the full flow.

Steps typically include:

1. Set up the Inngest app in your IdP

   • Create an enterprise application (e.g., “Inngest – Prod”).
   • Configure Entity ID, ACS URL, and NameID as provided by Inngest.
   • Add basic attributes (email, names, groups).

2. Exchange metadata with Inngest

   • You provide:
     • IdP metadata XML or SSO URL, Entity ID, and signing certificate.
   • Inngest provides:
     • Service Provider (SP) Entity ID.
     • ACS URL.
     • Any required audience or recipient values.

3. Enable SSO in a controlled scope

   • Initially restrict access to a small pilot group (platform/SRE).
   • Keep password-based login available as a fallback until you validate the flow.

4. Test the full lifecycle

   • First-time login (account creation / linking via SAML).
   • Logout and re-login.
   • Group-based access (if configured).
   • Deprovisioning test:
     • Remove a user from the Inngest app in your IdP.
     • Confirm they lose access to Inngest.

Only after this passes do most teams enforce SSO for all users.

Phase 3: RBAC Configuration & Validation

Goal: Set up roles so your teams can ship workflows safely without over-privilege.

Steps:

1. Define organization-level admins

   • Map 1–2 IdP groups (e.g., “Platform-Admins” or “Security-Admins”) to Org Admin.
   • Confirm who can:
     • Manage SSO.
     • Create workspaces.
     • Change org-wide settings and billing.

2. Set up workspaces and roles

   • Create workspaces (e.g., product-x-prod, product-x-staging, shared-tools).
   • Assign workspace-level roles:
     • Platform/SRE as Workspace Admin.
     • Feature teams as Developers or Contributors.
     • Observability/audit as Read-only.

3. Validate permissions

   • With test accounts, confirm:
     • Org Admin can manage security and workspaces.
     • Developers can:
       • Deploy functions using inngest.createFunction().
       • Run locally via npx --ignore-scripts=false inngest-cli dev.
       • View Traces and Replay for their own workspace.
     • Read-only users can inspect Traces, structured logs, and step-level inputs/outputs but cannot modify functions or Flow Control.

4. Lock down critical paths

   • Ensure only trusted roles can:
     • Change concurrency keys, throttling, and prioritization for multi-tenant workloads.
     • Trigger Bulk Cancellation or bulk Replay across large sets of runs.
     • Configure sensitive integrations or environment secrets.

Phase 4: Rollout, Training & Operational Readiness

Goal: Gradually roll Inngest out to more teams while keeping access safe and predictable.

Activities:

• Gradual expansion
  • Add more teams to the Inngest SAML app in your IdP.
  • Confirm their role mappings behave as expected.
• Training and enablement
  • Short sessions for developers:
    • How to wrap business logic in Steps using step.run().
    • How to use Traces to debug and Replay to recover.
  • Short sessions for SRE/platform:
    • How to monitor executions and flow control.
    • How to handle incidents (query, cancel, or replay runs safely).
• Runbooks
  • Document:
    • How to onboard a new engineer (IdP group + expected Inngest role).
    • How to offboard an engineer (remove from IdP groups; verify access revocation).
    • Who to contact for changes to SSO or RBAC.

Phase 5: Ongoing Governance

Goal: Keep access tight as your usage grows.

Typical longer-term practices:

• Quarterly access reviews
  • Confirm Org Admins and Workspace Admins are still correct.
  • Check for any direct role assignments that should be replaced with group-based assignments.
• Audit and compliance
  • Use Inngest’s real-time traces and structured logs plus your IdP’s audit logs to:
    • Validate who has access.
    • Trace who triggered Replay or Bulk Cancellation for sensitive pipelines.
• Scale and new teams
  • As you add new workflows (like AI agents, RAG pipelines, or multi-tenant connectors), create dedicated workspaces and adjust RBAC boundaries accordingly.

---

Impact on Developer Experience

Done well, SAML SSO and RBAC fade into the background for your engineers:

• Sign-in is seamless

  • “Continue with SSO” becomes the only path.
  • MFA and device checks are handled by your IdP.

• Developers stay in code

  • They work with familiar primitives:

    import { inngest } from "./client";
    
    export const processWebhook = inngest.createFunction(
      { id: "process-webhook" },
      { event: "app/webhook.received" },
      async ({ step, event }) => {
        const payload = await step.run("validate-payload", async () => {
          // business logic only
          return validate(event.data);
        });
    
        await step.run("apply-changes", async () => {
          return applyChanges(payload);
        });
      }
    );
    

  • Inngest handles retries, checkpointing, and observability; RBAC just ensures only the right people can deploy or operate this function.

• SREs and platform engineers get the control surface they need

  • Traces to see every step, input, and output.
  • Replay and Bulk Cancellation to recover from partial failures at scale.
  • Flow Control to keep noisy tenants from taking down the rest—without re-architecting workers or queues.

All of this sits behind your SAML SSO and RBAC policies, so the people touching these controls are exactly who you intend.

---

What You Need Before You Start

To make SAML SSO and RBAC onboarding smooth, have these ready:

• An Enterprise agreement with Inngest that includes SAML SSO and RBAC.
• An IdP admin who can:
  • Create/edit SAML applications.
  • Configure group assignment and attributes.
• A security or platform owner who will:
  • Define your initial access model.
  • Own long-term governance.
• A pilot team (usually platform/SRE) to test access and workflows before wider rollout.

---

Final Verdict: How to Think About Enabling SAML SSO & RBAC

Enabling SAML SSO and RBAC in Inngest Enterprise isn’t just flipping a switch—it’s about designing how your teams will safely ship and operate durable workflows, AI agents, and background jobs at scale.

The core decision frame:

• If you want centralized, compliant access control: Start with SAML SSO, enforced for all users, with IdP-backed deprovisioning.
• If you want safe operational power: Use RBAC to limit who can change Flow Control, Replay in bulk, or adjust critical settings, while giving developers the freedom to iterate in code.
• If you’re planning multi-tenant or high-throughput workloads: Treat SSO and RBAC as part of your architecture from day one; they’re as important as concurrency keys and retries.

When you’re ready to formalize this for your organization, your next step is to connect with the Inngest team and walk through the Enterprise onboarding plan tailored to your IdP and security stack.

Next Step

Get Started