Vord

Architecture Decision Record

0047. Legacy-protocol and adjacent-product posture

Context

A capability comparison against Microsoft Entra ID surfaced a set of surfaces Vord had neither adopted nor declined — LDAP serving, Kerberos, WS-Fed, RADIUS, device management, workload identity federation, and the access-gateway product family. Undecided scope is how projects sprawl: each of these has a plausible customer ask, and each would quietly bend the architecture if adopted by drift. ADR-0014 set the precedent of explicit declines (ROPC, the implicit flow, introspection); this record applies the same discipline to the remaining perimeter, recording the maintainer's scope decisions so the Entra comparison is honest about what Vord is not.

Decision

  1. LDAP: sync-source only; the serving interface is declined. Vord consumes AD/LDAP as an inbound synchronization source — proposal 0017's role, unchanged and affirmed. Vord does not expose an LDAP bind/query interface for applications: an LDAP head would put a stateful, password-carrying legacy protocol in front of the directory, its consumers are precisely the applications the OIDC/SAML surface exists to migrate, and its semantics (per-connection bind state, plaintext-adjacent simple bind) fight the token-based model end to end. Operators with immovable LDAP-speaking applications should keep their existing directory for those applications and let Vord sync from it — the pattern proposal 0017 already assumes. Declining the serving interface does not decline LDAP as a credential verifier inside the login ceremony (bind-as-user against an operator's directory): that is an authentication method under ADR-0015's extension contract, and the migration JIT verifier (proposal 0014) is its first sanctioned use.

  2. Kerberos: declined. Ticket-granting semantics belong to the domain-services world (machine trust, domain join) that Vord deliberately does not enter; there is no edge-verifiable analog of a TGT that would honor rule 1, and the demand cases are MDM/domain-adjacent (decision 5). No Kerberos issuance, no Kerberos bridging. As with LDAP, the decline is about Vord speaking Kerberos as a service: consuming a SPNEGO ticket as a login-ceremony verifier (desktop SSO at the hosted login page) remains expressible as an out-of-tree ADR-0015 method — deliberately unshipped, structurally possible.

  3. WS-Fed and RADIUS: declined. WS-Fed is the legacy-federation protocol SAML 2.0 already supersedes in every modern catalog — SAML 2.0 (ADR-0017) is Vord's legacy-federation ceiling, and WS-Fed joins ROPC and the implicit flow in ADR-0014's declined set in spirit. RADIUS serves network-access control (VPNs, Wi-Fi), a NAC-product concern; identity for such systems arrives via SAML/OIDC gateways on the vendor side, not via Vord speaking RADIUS.

  4. Workload identity federation: deferred, seat named — not declined. Exchanging an external issuer's OIDC token (CI systems, cloud workloads) for a Vord token is architecturally clean — a trust-policy object plus an exchange profile on the already-reserved RFC 8693 seat (ADR-0014) — and is expected to matter. It is not built now by explicit maintainer decision; when demand triggers it, it is additive on the reserved seat with no format or model change. This is the reserved-seat pattern, applied with a named "not yet".

  5. Device management (MDM): out of scope for now. Devices remain risk- signal inputs consumed at issuance (ADR-0031: registered authenticators, passkey device binding, posture attestations from external MDMs) — never managed objects with a Vord-owned enrollment/compliance lifecycle. The revisit trigger is explicit: a committed operational owner whose adoption depends on it, weighed as a product-line decision rather than a feature.

  6. Access-gateway and entitlement-adjacent products: out of scope. Application proxies / ZTNA / SSE (network-path products) and cloud- infrastructure entitlement management (CIEM) are adjacent product categories Vord integrates with (as their IdP), not product lines it grows. The scope boundary of the architecture overview (§1.5 — Vord is not the resource it protects) already implies this; it is now decided, not implied.

Consequences

  • The comparison against full-suite incumbents is honest by construction: organizations that need a served LDAP directory, Kerberos/domain services, or an MDM should not adopt Vord for those needs, and the docs can say so plainly instead of hedging.
  • Every decline is cheap to hold and expensive to reverse by accident: reversing one is a superseding-ADR event with the burden of argument on the adoption, mirroring ADR-0014's posture.
  • The one deferral (workload identity federation) keeps its reserved seat, so "not now" never hardens into "cannot".
  • Sync-source LDAP (proposal 0017) gains an affirmed boundary: the connector reads and reconciles; nothing in Vord answers LDAP.
  • Refines the scope statements of the architecture overview (§1.5) and composes with ADR-0014's declined set, ADR-0025's certify-what-ships rule (no conformance targets exist for declined protocols), and ADR-0031 (devices as signals).