Workspace in the DarDev pipeline (Authorize step)

Workspace is DarDev's zero-trust identity and access management layer—the Authorize step in our product platform pipeline. Before engineers open a DarDevCDE lab, a GitLab pipeline deploys to Kubernetes, or Grafana dashboards load, Authorize answers who the actor is, which tenant they belong to, and what they may do next. One identity plane replaces duplicated LDAP configs and ad hoc OAuth clients scattered across repos.

We publish under Deployed Realities: this guide describes what we operate on dardev-vps and client pilots, not a hypothetical IAM product sheet. If you are mapping your own multi-product stack, treat Authorize as mandatory middleware—not a login page you bolt on after shipping three apps.

The four steps: where Authorize sits

DarDev organizes delivery around four steps—Authorize, Develop, Deploy, Observe—each backed by a product we dogfood. Workspace owns Authorize; DarDevCDE owns Develop; DarDevOps owns Deploy; our observability stack owns Observe. Steps are sequential in architecture, not calendar order: you can pilot Deploy before every SSO detail is perfect, but you must not skip Authorize when humans touch production data.

1. Authorize (Workspace): authentication, federation, group sync, session policy
2. Develop (DarDevCDE): consistent tooling without laptop drift
3. Deploy (DarDevOps): namespaces, ingress, CI tokens scoped to least privilege
4. Observe: alerts and audit trails keyed to the same identities Authorize issued

Authorize feeds the other steps with signed context—subject ID, tenant scope, group membership—not shared admin passwords. When a cohort instructor opens browser VS Code, Workspace bounds the session to that namespace; DarDevOps provisions it; Observe ties lab errors to that identity. Break Authorize and you get open admin panels or untraceable changes.

What Workspace handles in production

Workspace centralizes OIDC and SAML configuration, redirect URIs, and group-to-role mappings for GitLab, Grafana, internal admin tools, and selected customer-facing surfaces. Human logins federate here; machine actors use separate scoped credentials documented in our zero-trust IAM for internal SaaS guide. We do not clone the same OAuth client secret into every microservice repository—doing so guarantees a staging leak becomes a production incident.

Cross-app SSO follows one canonical subject per person. Group membership flows from tenant role tables into GitLab groups and Grafana org roles without granting cluster-admin shortcuts. The SSO across GitLab, Grafana, and custom apps article covers redirect URI hygiene, logout behavior, and why group sync must be tested before you announce enterprise SSO to procurement.

Multi-tenant products—Hesabi, DarDevLab surfaces, internal CRM and mailer admin—keep business data separate but share authentication through Workspace where possible. Identity for multi-tenant product platforms covers org-scoped tokens and tenant middleware.

Authorize in DarDevLab and cohort pilots

DarDevLab learners still use product-native accounts at dardevlab.com. Workspace already gates browser labs for instructor-led DarDevCDE cohorts—one login, cohort-scoped session, no local Docker. Full SSO across every lab surface is roadmap; see dardevlab-workspace-sso-roadmap for current scope.

Implementation checklist

1. Inventory actors and surfaces

   List every human role, service account, CI job, and break-glass path. If it can mutate data or infrastructure, it belongs in Authorize scope.

2. Centralize IdP config in Workspace

   Start with OIDC; add SAML when enterprise customers require it. Keep secrets out of application repos.

3. Scope Deploy credentials

   GitLab deploy tokens and Kubernetes service accounts should reach only the namespaces they need—never cluster-admin for convenience.

4. Tighten admin sessions

   CRM, campaign prep, and sync-worker UIs need shorter idle timeouts and step-up auth for destructive actions. Session security patterns for admin tools covers fixation risks and rotation.

5. Wire Observe to identity

   Audit logs and alerts should include subject and tenant keys so on-call engineers trace actions without guessing from IP alone.

Common mistakes

• Per-app bespoke auth that diverges on password reset and MFA policy
• Shared OAuth clients across staging and production
• CI pipelines using human admin sessions or cluster-admin tokens
• Announcing SSO before group sync, logout, and session revocation are tested
• Treating Authorize as finished once the first OIDC login works in a demo

How DarDev helps

Workspace is our Authorize product—zero-trust IAM and SSO patterns we reuse as we add platform steps and customer apps. Visit dardev.net/products for positioning, read how we dogfood the full stack on dardev-vps, and subscribe to Workspace updates at mail.dardev.net/subscribe/workspace-marketing.html if you are evaluating federated identity for a multi-product SaaS stack.