Vord

Enhancement Proposal

Proposal: Integration catalog and app templates

Okta's OIN and Auth0's marketplace are half the reason enterprises integrate in an afternoon: the connection to Salesforce is pre-built and tested, not reverse-engineered from the target's docs. This specs Vord's equivalent — per-app connection templates that are data, not code, instantiated through the ordinary admin surfaces. No new execution surface, no new architecture.

Motivation

"Connect Salesforce" should not require reading Salesforce's SAML documentation. Each common target (Salesforce, Slack, AWS, Google Workspace, GitHub, …) has quirky SAML/OIDC parameters and SCIM attribute maps; every operator rediscovering them is duplicated work and — because identity misconfiguration is a security hole — duplicated risk. The enterprise targets need SAML (M6, ADR-0017) and SCIM (M7, ADR-0018), which sets the milestone.

Design

  • A template is data, never code: a versioned config artifact that instantiates an OAuth/OIDC client (ADR-0038), a SAML SP registration (ADR-0017), and/or a SCIM provisioning target with attribute mappings (ADR-0018) — parameter presets plus a setup guide for the target's side. There is no execution surface: extensibility-by-code is ADR-0029's, and templates deliberately are not it.
  • A public, community-contributable catalog repo, validated in CI against the conformance fixtures — ADR-0025's discipline applied to integrations: a template that does not validate does not merge.
  • Instantiation goes through the admin API / config-as-code (ADR-0021, proposal 0023): a template instance is ordinary reviewed configuration — diffable, promotable, and audited (ADR-0022) like any other config change.
  • Quality tiers — verified and community — with the verified tier held to the governance model's maintainer-review bar (ADR-0007) on top of CI validation.

Alternatives considered

  • An in-product marketplace service — rejected for v1: a git catalog plus CI is control-resilient in the sense ADR-0008 tests for (no service whose loss strands operators) and far cheaper; the admin console (proposal 0018) can render the catalog later.
  • Per-app code plugins — rejected: templates are data; execution and extensibility are ADR-0029's, and a code surface per app is an unauditable attack surface.

Graduation criteria

The catalog exists with verified templates covering the common enterprise targets; each verified template validates in CI against the conformance fixtures; instantiating one through the admin API / config-as-code yields a working SAML/OIDC and (where offered) SCIM connection; and the instance is visible as ordinary audited configuration.

Backward compatibility

Templates instantiate existing object kinds — clients, SAML SPs, SCIM targets — through existing APIs, so there is nothing new to migrate. Templates version per-template, and an instantiated config records which template version produced it.

Open questions

  • Catalog repo location and naming: in-tree versus a separate repository under the org.
  • Whether verified-tier testing requires live sandbox tenants of each target SaaS (real round-trips) or the conformance fixtures suffice — and who pays for and maintains the sandboxes.