Merge pull request #124 from theta42/feature/openbao-secrets

v1.28.0: OpenBao as the central secrets store for the stack
2026-08-01 12:55:32 -04:00 · 2026-08-01 12:54:56 -04:00 · 2026-08-01 11:14:39 -04:00 · 2026-08-01 11:13:51 -04:00 · 2026-08-01 10:27:38 -04:00 · 2026-08-01 10:26:59 -04:00
18 changed files with 1283 additions and 48 deletions
@@ -2,7 +2,9 @@ name: Lint

 # theta-env has no app code of its own to unit-test (it orchestrates the
 # proxy/sso-manager-node submodules) -- this checks the one thing that can
-# actually break silently: setup.sh and bootstrap.js.
+# actually break silently: setup.sh and bootstrap.js, plus a static
+# consistency check on the config bootstrap.js generates for jump-host
+# (test/check_jump_ldap_tls.js).
 on:
  pull_request:
    branches:
@@ -39,3 +41,6 @@ jobs:

      - name: Syntax check
        run: node --check bootstrap/bootstrap.js
+
+      - name: Jump-host LDAP config consistency
+        run: node test/check_jump_ldap_tls.js
@@ -5,8 +5,12 @@
 config/
 backups/

-# Legacy .env / proxy.env (no longer used — config is in ./config/). Still
-# ignored in case a migrated deployment hasn't deleted them yet.
+# .env: NOT app config (that's ./config/, generated by setup.sh) — this is
+# docker compose's own auto-loaded env file, which setup.sh uses only to
+# persist *_GIT_COMMIT build args so an ad-hoc rebuild of a single service
+# still bakes the right commit hash. Generated; never commit.
+# proxy.env: legacy, no longer used — still ignored in case an old
+# deployment hasn't deleted it yet.
 .env
 proxy.env

@@ -8,3 +8,6 @@
 	path = jump-host
 	url = https://github.com/theta42/jump-host.git
 	branch = master
+[submodule "ldap-client"]
+	path = ldap-client
+	url = https://github.com/theta42/ldap-client.git
@@ -8,8 +8,502 @@ orchestration code; see each submodule's own `CHANGELOG.md`
 [sso-manager-node](https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md))
 for what changed inside the apps it composes.

+## [v1.28.0] - 2026-08-01
+
+OpenBao becomes the central secrets store for the whole stack. Every app now
+loads its secrets from OpenBao at boot via the new
+[`@simpleworkjs/bao-conf`](https://simpleworkjs.github.io/bao-conf/) package;
+end users get personal per-user secret storage through the SSO UI; external
+apps get scoped `secret/apps/<app>/*` access. `setup.sh` mints the policies
+and scoped tokens, `bootstrap.js` writes generated creds into OpenBao, and a
+new `docs/secrets.md` documents the architecture.
+
+### Changed (theta-env orchestration)
+- **`setup.sh`** — after the KV-v2 enable, a new idempotent block writes four
+  OpenBao policies (`sso-broker`, `sso-admin`, `proxy`, `jump-host`) via
+  heredocs, a `sso-broker` token role (`allowed_policies_glob` `user-*`/`app-*`,
+  24h period), and mints scoped `SSO_VAULT_TOKEN` / `PROXY_VAULT_TOKEN` /
+  `JUMP_VAULT_TOKEN` (orphan, renewable, reused from `setup.env` if still
+  valid). `seed_app_conf` seeds `secret/{sso-manager,proxy,jump-host}/conf`
+  from the operator-edit `/config/*-secrets.js` files on first run. The
+  bootstrap exec now passes the root `VAULT_ADDR`/`VAULT_TOKEN` for seeding.
+  The root token stays in `setup.env` for maintenance only — it is never passed
+  to a service container. `bash -n` + `shellcheck` clean.
+- **`docker-compose.yml`** — `sso-manager`/`proxy`/`jump-host` get
+  `VAULT_ADDR=http://openbao:8200` and `VAULT_TOKEN=${SSO|PROXY|JUMP}_VAULT_TOKEN:-`;
+  `proxy`/`jump-host` gain `depends_on: openbao: service_started`. compose
+  config valid.
+- **`bootstrap/bootstrap.js`** — `baoPut()` writes the generated OAuth client
+  creds to `secret/proxy/conf` and `secret/jump-host/conf` (POST replaces; the
+  full file object), so OpenBao — not the on-disk `/config/*-secrets.js` — is
+  authoritative after first boot. Fail-soft. `node --check` clean.
+- **`docs/secrets.md`** (new) — the full secrets architecture: load path,
+  policy/token table, the `sso-broker` role, seeding, end-user personal
+  secrets, external-app convention (curl + Node `bao-conf` examples), operator
+  rotation, backups. Linked from the README and the docs nav (`_config.yml`).
+- **README** — Configuration section rewritten (OpenBao authoritative, link to
+  `docs/secrets.md`); Secrets-backup section adds the `openbao-data` volume.
+
+### Submodule bumps
+- `sso-manager-node` → **v1.16.0** (was v1.15.2-era).
+- `proxy` → **v1.13.1** (was v1.12.1; passes through v1.13.0).
+- `jump-host` → **v1.14.1** (was v1.11.0-era; passes through v1.14.0).
+- `ldap-client` unchanged (v1.1.1).
+
+#### sso-manager-node — [v1.16.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.16.0)
+
+OpenBao becomes the central secrets store for the theta42 stack, and the SSO
+Manager becomes its broker. This is the SSO's half of the move: it loads its
+own secrets from OpenBao, mints scoped tokens for users and external apps,
+and exposes a fixed, role-scoped personal-secrets UI.
+
+##### Changed
+- **Secrets now load from OpenBao at boot** via
+  [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+  deep-merges `secret/sso-manager/conf` over the file-loaded config
+  (replacing the old `utils/conf_manager.js`, which did a shallow-per-key
+  merge). `bin/www` runs `bao-conf.init()` after `models.initORM()` and
+  before `listen`. Fail-soft: if OpenBao is unreachable, boot continues from
+  `CONF_SECRETS`. The SSO authenticates with a scoped `VAULT_TOKEN` (policy
+  `sso-broker`), never the root token. The admin **Configuration** UI
+  (`/api/conf`) now writes through `bao-conf.set('sso-manager', …)`.
+- **`/api/vault` proxy reworked** — the old endpoint was an ungated
+  pass-through that never injected an `X-Vault-Token` (so the UI was both
+  ungated *and* broken). It is now `middleware.auth` → `scopeGuard` → a
+  token-injecting proxy. `scopeGuard` resolves a per-user (`user-<uid>`) or
+  per-admin (`sso-admin`) token via the new `utils/vault_broker.js`
+  (Redis-cached, minted through the `sso-broker` token role) and enforces a
+  path prefix as a second layer on top of the OpenBao policy. The client
+  `auth-token` is stripped; only the server-minted token reaches OpenBao.
+- **Vault UI reworked and renamed** (`views/vaultwarden.ejs` →
+  `views/vault.ejs`; the `/vault` route is now `middleware.auth`-gated).
+  Non-admin users see only their `secret/users/<uid>/` namespace; admins get
+  free-form path entry across `secret/` plus an **Apps** tab to mint scoped
+  tokens for external apps (`secret/apps/<name>/*`, shown once with copy +
+  `curl` convention).
+- Bumped package version to track the release tag.
+
+##### Removed
+- `nodejs/utils/conf_manager.js` (replaced by `@simpleworkjs/bao-conf`).
+- `nodejs/views/vaultwarden.ejs` (renamed `vault.ejs`).
+
+##### Security
+- **Committed-secrets remediation.** `config/sso-secrets.js` (LDAP bind
+  password, SMTP, `oauth.jwtSecret`) and `nodejs/test_plugins.js` (a
+  hardcoded Proxmox root API token and a UniFi password) were tracked on
+  master. They are now untracked + gitignored (`config/*-secrets.js`), and
+  `test_plugins.js` is deleted; `config/proxy-secrets.js.example` added as a
+  placeholder template. **The secrets remain in git history — rotation at
+  the providers is the real remediation and is the operator's to perform.**
+  OpenBao is now the authoritative store; the local files are seed artifacts
+  only.
+
+> Note: sso releases v1.12.0–v1.15.2 were tagged from merge PRs without
+> corresponding `CHANGELOG.md` entries or GitHub releases; v1.16.0 resumes
+> the changelog.
+
+#### proxy — [v1.13.1](https://github.com/theta42/proxy/releases/tag/v1.13.1) (via [v1.13.0](https://github.com/theta42/proxy/releases/tag/v1.13.0))
+
+##### v1.13.1 — Fixed
+- **Bumped `@simpleworkjs/bao-conf` to 1.0.1** so standalone/no-OpenBao boots
+  don't crash. bao-conf 1.0.0's `init()` threw when `VAULT_TOKEN` was unset,
+  which — combined with `bin/www`'s `.catch(() => process.exit(1))` — made the
+  proxy exit at boot in any deployment without an OpenBao sidecar (standalone
+  Docker, bare metal). 1.0.1 makes `init()` fail-soft on a missing token (warn
+  + continue from `CONF_SECRETS`), matching the documented contract. The
+  theta-env stack is unaffected (it always sets a scoped `VAULT_TOKEN`).
+
+##### v1.13.0 — Changed
+- **Secrets now load from OpenBao at boot** via
+  [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+  deep-merges `secret/proxy/conf` over the file-loaded config. The proxy
+  authenticates to OpenBao with a scoped `VAULT_TOKEN` (policy `proxy` —
+  read-only on its own path), never the root token. Because the OIDC
+  `clientSecret` is captured at require time inside `createOidcClient` (during
+  `require('../models')`, which `require('../app')` triggers transitively),
+  `bin/www` now defers `require('../app')` until after `bao-conf.init()`
+  resolves. Fail-soft: if OpenBao is unreachable, boot continues from
+  `CONF_SECRETS`. The `config/proxy-secrets.js` file is now an operator-edit
+  seed artifact (gitignored); OpenBao is authoritative.
+- Bumped package version to track the release tag.
+
+#### jump-host — [v1.14.1](https://github.com/theta42/jump-host/releases/tag/v1.14.1) (via [v1.14.0](https://github.com/theta42/jump-host/releases/tag/v1.14.0))
+
+##### v1.14.1 — Fixed
+- **Bumped `@simpleworkjs/bao-conf` to 1.0.1** so standalone/no-OpenBao boots
+  don't crash. bao-conf 1.0.0's `init()` threw when `VAULT_TOKEN` was unset,
+  which — combined with `bin/www`'s `.catch(() => process.exit(1))` — made the
+  jump host exit at boot in any deployment without an OpenBao sidecar
+  (standalone Docker, bare metal). 1.0.1 makes `init()` fail-soft on a missing
+  token (warn + continue from `CONF_SECRETS`), matching the documented
+  contract. The theta-env stack is unaffected (it always sets a scoped
+  `VAULT_TOKEN`).
+
+##### v1.14.0 — Changed
+- **Secrets now load from OpenBao at boot** via
+  [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+  deep-merges `secret/jump-host/conf` over the file-loaded config. The jump
+  host authenticates to OpenBao with a scoped `VAULT_TOKEN` (policy
+  `jump-host` — read-only on its own path), never the root token. Because the
+  OIDC `clientSecret` is captured at require time inside `createOidcClient`
+  (during `require('../models')`), `bin/www` now runs `bao-conf.init()`
+  **before** `require('../models')`. Fail-soft: if OpenBao is unreachable,
+  boot continues from `CONF_SECRETS`. The `config/jump-secrets.js` file is now
+  an operator-edit seed artifact (gitignored); OpenBao is authoritative.
+- Bumped package version to track the release tag.
+
+## [v1.27.2] - 2026-08-01
+
+- Updated `proxy` to v1.12.1 (Dependabot security/maintenance bumps).
+
+#### proxy — [v1.12.1](https://github.com/theta42/proxy/releases/tag/v1.12.1)
+
+##### Changed
+- Bumped `body-parser` 2.2.2 → 2.3.0 (Dependabot #175).
+- Bumped `ejs` and `brace-expansion` (Dependabot #179, security maintenance).
+
+## [v1.27.1] - 2026-08-01
+
+- Added automated integration tests for the environment (`test-integration.sh`).
+- Updated `sso-manager-node` to v1.15.2 (Directory UI tab styling fixes and Vault documentation).
+
+## [v1.27.0] - 2026-08-01
+
+- Updated `sso-manager-node` to v1.15.0 (UI/UX improvements and structured conf page).
+
+## [v1.26.0] - 2026-08-01
+
+- Made OpenBao production-ready by using a persistent file backend, enabling `IPC_LOCK`, and dynamically generating a robust config file.
+- Automated OpenBao initialization, unsealing, and secrets seeding via `setup.sh`.
+
+## [v1.25.0] - 2026-08-01
+
+- Added OpenBao (Vault) container for secrets management and native UI proxying.
+- Updated `sso-manager-node` to v1.14.0 (Discovery and Vault integration).
+- Updated `proxy` to v1.12.0.
+
 ## [Unreleased]

+## [1.23.0] - 2026-07-31
+
+### Submodules bumped
+- jump-host `v1.12.0` -> [`v1.13.0`](https://github.com/theta42/jump-host/releases/tag/v1.13.0)
+- proxy `v1.10.0` -> [`v1.11.0`](https://github.com/theta42/proxy/releases/tag/v1.11.0)
+- sso-manager-node `v1.12.0` -> [`v1.13.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.13.0)
+
+#### jump-host — [v1.13.0](https://github.com/theta42/jump-host/releases/tag/v1.13.0)
+
+##### Changed
+- **Title changed to "SSO Manager"** — the jump-host web UI now presents itself as "SSO Manager" in the navbar and page title, matching its role as the unified access portal for both services and hosts.
+
+#### sso-manager-node — [v1.13.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.13.0)
+
+##### Changed
+- **Directory page cleaned up** — removed the parent badge and slug display from the directory table; resource names now align with the badges above for a cleaner, more compact layout.
+- **Users list SSH key column fixed** — users with multiple SSH keys no longer show multiple checkmarks; the column now shows a single checkmark indicating "has key" regardless of key count.
+
+#### proxy — [v1.11.0](https://github.com/theta42/proxy/releases/tag/v1.11.0)
+
+##### Changed
+- **Permissions, Users, and Groups pages converted to table layouts** — card grids replaced with striped tables for better scanability and alignment. Users page adds per-field validation error display alongside the summary message.
+- **Groups page auto-refreshes** — adding or removing a group now triggers an explicit reload, ensuring the list stays in sync without manual refresh.
+
+## [1.22.0] - 2026-07-31
+
+### Submodules bumped
+- jump-host `v1.11.0` -> [`v1.12.0`](https://github.com/theta42/jump-host/releases/tag/v1.12.0)
+- proxy `v1.9.0` -> [`v1.10.0`](https://github.com/theta42/proxy/releases/tag/v1.10.0)
+- sso-manager-node `v1.11.0` -> [`v1.12.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.12.0)
+
+#### jump-host — [v1.12.0](https://github.com/theta42/jump-host/releases/tag/v1.12.0)
+
+##### Added
+- **TUI host picker with colors**: ANSI-colored terminal UI with box-drawing header, cyan/magenta/green title treatment, per-row coloring (cyan hostnames, blue IPs), environment badges (red PROD / dim DEV), green inverse selection highlight with "◄ SELECTED ►" indicator, yellow filter text, and a footer separator with quick-select hint.
+
+#### sso-manager-node — [v1.12.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.12.0)
+
+##### Changed
+- **Catalog page (`/`) redesigned**: Removed the portal banner; "My Access" section now has tabs separating Services and Hosts; icons support both Font Awesome classes and image URLs (http/https).
+- **Profile page redesigned as a single card with tabs**: Password reset is now a modal button; "My groups", "My Services", "Security & Usage Stats", and "Members of X's group" are now tabs on the main profile card instead of separate cards; metrics display fixed to properly load and show service usage data.
+
+#### proxy — [v1.10.0](https://github.com/theta42/proxy/releases/tag/v1.10.0)
+
+##### Changed
+- **Permissions page**: Converted from card grid to table/list layout with columns: Subject, Scope, Domain, Role, Actions.
+- **Users page**: Converted from card grid to table/list layout; form validation now shows both a summary message AND per-field error messages with visual highlighting.
+- **Groups page**: Added automatic refresh after adding/deleting groups to ensure new entries appear immediately.
+
+## [1.21.0] - 2026-07-31
+
+### Submodules bumped
+- ldap-client `v1.1.0` -> [`v1.1.1`](https://github.com/theta42/ldap-client/releases/tag/v1.1.1)
+- sso-manager-node `v1.10.0` -> [`v1.11.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.11.0)
+
+> **Operational note — the SSO image now builds slapd from source.** OpenLDAP's
+> `nestgroup` overlay (nested groups) exists only on master; no 2.6.x release
+> ships it. `Dockerfile.openldap` therefore compiles OpenLDAP from a **pinned**
+> commit, which makes the SSO image slower to build and pulls `pw-sha2` from
+> contrib. Two consequences worth knowing:
+>
+> - Master ships **LMDB 1.0.0**, whose on-disk format is mutually unreadable
+>   with the 0.9.x in 2.6.x (`MDB_INVALID: File is not an LMDB file`). Moving an
+>   existing `/var/lib/ldap` onto this image is a `slapcat` -> `slapadd` reload,
+>   not a restart.
+> - There is a `TODO` to drop the whole from-source stage once `nestgroup` ships
+>   in a release. The entrypoint already probes for `nestgroup.so` and the app
+>   keys off `app_ldap__nestedGroupsServerSide`, so that swap needs no other
+>   changes.
+
+#### sso-manager-node — [v1.11.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.11.0)
+
+##### Added
+- **End-user catalog at `/`** — the first ungated nav item; previously every nav entry was admin-only and a normal user had no signposted destination. Search/filter, per-kind icons, and a *how to reach it* block per card: the URL for a service, the SSH invocation for a host (using the jump-host `uid_-_slug@host` grammar when `directory.jumpHost` is set).
+- **Self-service access requests** — `/api/access-requests` (create, list own, list decidable, approve, deny, withdraw) with approve/deny queues on the catalog. Approving performs the LDAP group add, so LDAP stays the access-control truth. Requests target a resource's `_access` group, never `_admin`. Replaces the "coming soon" stub.
+- **Admin access visibility** — an Access column on the directory table (member/group counts, flagging links whose LDAP group was deleted) and a "what can this user reach" lookup, the reverse question that previously had no UI at all.
+- **Nested LDAP groups.** `groupOfNames.member` already accepts a group DN, so nesting needs no schema — what it needs is resolution, which no released OpenLDAP performs. Server-side via the pinned-master `nestgroup` overlay; client-side the app computes the closure itself (cycle-detected, depth-capped) against any other server. `PUT`/`DELETE /api/group/:group/nested/:child`, `GET /api/group/:group/effective`, and a **Nested** tab on each group card.
+- **`app_super_admin` is now seeded** (it never was) and nested into `app_sso_admin` / `app_sso_invite` / `app_sso_oauth_admin`, so the privilege is real LDAP membership visible to SSSD and sudo rather than a special case in app code. Resource creation nests `app_super_admin` -> `<slug>_admin` and `<slug>_admin` -> `<slug>_access`.
+- Resource metadata `icon` and `tagline`, collected on the admin form with a live icon preview.
+
+##### Fixed
+- **`GET /api/discovery/me` returned only `isPublic` resources for every human caller** — it read `req.user.groups`, which does not exist (`req.user` carries `memberOf`), so the empty list failed open. "My Services" was blank for everyone, and `isDirectoryAdmin()` was false even for real directory admins.
+- **The portal's "Discover More Services" was dead for every non-admin** — it called the admin-gated endpoint and swallowed the 403 into an empty array.
+- **Services reported no address** — `/me` had reimplemented `getMyAccess` without its parent-walking resolution, so a service reached at its host's IP resolved to nothing.
+- `GET /api/user/me` derived `isAdmin` from `memberOf`, which is only transitive with `nestgroup`; against a stock server an admin holding their group via nesting lost the entire admin UI while still passing every server-side check.
+- `utils/permission.js`'s `byGroup` saw only direct membership.
+- Adding an existing group member, and removing a group's last member, both returned bare 500s; now 409s that explain themselves.
+- `DELETE /api/directory-admin/resources/:id` deleted the resource before its edges and group links, orphaning rows on a mid-way failure.
+- `/api/directory-admin/audit-logs` shelled out to `tail` via `execSync`; replaced with a bounded async read.
+- Broken `api.html` link in the published docs.
+
+##### Changed
+- `@simpleworkjs/directory-schema` -> `^1.1.0`, declaring ten metadata keys the admin form always wrote but the schema never listed. Undeclared keys are dropped for non-admin callers — which blanked the portal's `OS:` field, hid every service's port, and left machine tokens unable to read the port mapping the firewall consumer exists to render.
+
+#### ldap-client — [v1.1.1](https://github.com/theta42/ldap-client/releases/tag/v1.1.1)
+
+##### Fixed
+- Sets `ldap_group_nesting_level = 5` so SSSD walks nested groups itself when pointed at a server without `nestgroup`. Against the SSO's bundled slapd the existing `memberof=` access filter is already transitive, so SSH login inherits nesting for free. The explicit `app_super_admin` clause is kept, to keep super-admin login working against a directory predating the new nesting.
+
+
+## [1.20.0] - 2026-07-30
+
+### Added
+- **`setup.sh` persists `SSO_GIT_COMMIT`/`PROXY_GIT_COMMIT`/`JUMP_GIT_COMMIT` into `./.env`** (new `env_upsert` helper), which `docker compose` auto-loads on every future invocation in this directory. Previously these were only `export`ed for the current shell, so an ad-hoc `docker compose up --build <service>` run later (outside a full `setup.sh` run) would build with an empty `GIT_COMMIT` arg — and since each submodule's checked-out `.git` is a pointer file, not a real repo, the in-container git fallback can't resolve it either, so the image silently baked "unknown" as its commit hash. `.gitignore`'s `.env` comment updated to describe this (it was previously labeled "legacy, no longer used").
+
+### Submodules bumped
+- jump-host `v1.10.2` -> [`v1.11.0`](https://github.com/theta42/jump-host/releases/tag/v1.11.0)
+- ldap-client `v1.0.0` -> [`v1.1.0`](https://github.com/theta42/ldap-client/releases/tag/v1.1.0)
+- proxy `v1.8.0` -> [`v1.9.0`](https://github.com/theta42/proxy/releases/tag/v1.9.0)
+- sso-manager-node `v1.9.0` -> [`v1.10.0`](https://github.com/theta42/sso-manager-node/releases/tag/v1.10.0)
+
+#### sso-manager-node — [v1.10.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.10.0)
+
+##### Added
+- `app_super_admin` cross-app group: members are full admins here regardless of `app_sso_admin` membership. The same group is now also recognized by proxy and jump-host, and by `ldap-client`'s SSSD access filter (SSH login on every host).
+
+##### Changed
+- Renamed the Executive page to Overview (route, view, `/api/metrics/overview`, nav label, docs). `/executive` kept as a 301 redirect.
+
+#### proxy — [v1.9.0](https://github.com/theta42/proxy/releases/tag/v1.9.0)
+
+##### Added
+- `app_super_admin` cross-app group recognized as a global admin (`conf.auth.adminGroups`).
+
+##### Changed
+- Users and Permissions pages: the always-visible sidebar "Add" forms are now an "Add User"/"Add Permission" button that opens an `app.modal` dialog, matching the hosts.ejs convention.
+- Let's Encrypt ACME account key now defaults to the already-persisted `/data` volume instead of a CWD-relative path (`./le_key.cert` -> `/app/le_key.cert` in the container), which was lost on every image rebuild.
+
+#### jump-host — [v1.11.0](https://github.com/theta42/jump-host/releases/tag/v1.11.0)
+
+##### Added
+- `app_super_admin` (cross-app) and `app_jump_admin` groups: super admins are full admins here same as `app_sso_admin`; jump admins get audit page/data access without other admin rights. The Audit page/API is now actually admin-gated server-side (previously the page shell rendered for any logged-in user, only its data was gated).
+- Host list adds Last connection/Last failed connection columns and highlights rows green (a session is live right now) or yellow (the most recent attempt failed), backed by new per-host last-success/last-fail timestamps.
+
+##### Changed
+- Dashboard's stat boxes and Top hosts/Top users cards moved to the Audit page. "All hosts" renamed to "My hosts".
+
+#### ldap-client — [v1.1.0](https://github.com/theta42/ldap-client/releases/tag/v1.1.0)
+
+##### Added
+- `app_super_admin` cross-app group now grants SSH login access to every host (`ldap_access_filter` + `ldap_access_groups`), matching the same group's admin rights in sso-manager-node, proxy, and jump-host. Sudo is not yet extended to super admins (`ldap_sudo_search_filter` remains non-functional on this SSSD version — pre-existing, documented gap).
+
+## [1.19.0] - 2026-07-30
+
+### Added
+- **New `ldap-client` submodule + `ldap-test-host` service** (`jump-host` compose profile): a real SSSD + AuthorizedKeysCommand LDAP-joined downstream host for testing jump-host's actual key-injection -> upstream-connect flow end-to-end against this stack's own local LDAP, instead of a container with a manually-dropped public key in `authorized_keys`. Verified live (SSH CLI and WinSCP) through jump-host's `uid_-_target` grammar.
+
+#### ldap-client — [v1.0.0](https://github.com/theta42/ldap-client/releases/tag/v1.0.0) (first tagged release)
+
+##### Added
+- Docker test fixture (`Dockerfile` + `entrypoint.sh`): Ubuntu 22.04 + sssd + sshd, no systemd required.
+
+##### Fixed
+Building that fixture surfaced three real bugs that would break login on any deployment, not just the test fixture:
+- `sssd.conf.mo` used `ldap_bind_dn`/`ldap_bind_pw`, which aren't real SSSD options — corrected to `ldap_default_bind_dn` / `ldap_default_authtok(_type)`.
+- `sssd.conf.mo` had no explicit `services =` list, so SSSD started only its backend, never the nss/pam responders — `getent passwd <ldap-user>` silently failed even with the domain reachable.
+- `ldap-ssh-key.sh`'s `memberof` filter was missing the `cn=` prefix on the group name, so the AuthorizedKeysCommand script always returned zero keys for a correctly-provisioned user — no error, just silently nothing.
+
+#### sso-manager-node — [v1.9.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.9.0)
+
+##### Added
+- Directory modal's Associated LDAP Groups tab now supports full membership management: view, add, and remove members/owners of each associated group directly from the tab.
+- `app.util.revealItem()` (shared `app-base.js`): scrolls a just-added/-edited element into view and flashes its background.
+
+##### Changed
+- Groups page's search/sort bar is now sticky while scrolling.
+- Directory table: Kind/Name/Env/Host merged into a single "Resource" column.
+
+#### proxy — [v1.8.0](https://github.com/theta42/proxy/releases/tag/v1.8.0)
+
+##### Added
+- Users backed by SSO/OIDC login are now marked "External (SSO)" and read-only (password-change hidden client-side, `PUT /password/:username` rejects with 403 server-side). Redis user-backend only.
+
+##### Changed
+- All pages now wrap their content in a standard-width container, matching sso-manager-node instead of rendering full-bleed.
+- Users and Permissions pages converted from bare `<table>`s to the card-grid convention already used on the Groups page.
+
+#### jump-host — [v1.10.2](https://github.com/theta42/jump-host/releases/tag/v1.10.2)
+
+##### Changed
+- Dashboard, Sessions, and Audit pages now match sso-manager-node/proxy's page width.
+- Audit's nav entry is now admin-gated (`groups: ['admin']`).
+
+### Bumped
+- sso-manager-node -> [v1.9.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.9.0)
+- proxy -> [v1.8.0](https://github.com/theta42/proxy/releases/tag/v1.8.0)
+- jump-host -> [v1.10.2](https://github.com/theta42/jump-host/releases/tag/v1.10.2)
+- ldap-client -> [v1.0.0](https://github.com/theta42/ldap-client/releases/tag/v1.0.0) (new submodule)
+
+## [1.18.0] - 2026-07-28
+
+### Changed
+Cross-app API-token self-service UI unification: all 3 apps now share the
+same card-grid list, "+ New Token" modal-based create flow, `app.modal`-based
+secret reveal, and Edit modal (with real created-by/on audit metadata).
+
+#### sso-manager-node — [v1.8.2](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.2), [v1.8.3](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.3)
+
+**v1.8.2**
+
+##### Fixed
+- **Creating a new OAuth integration didn't reliably show the "save this client secret now" reveal modal** — `saveResource()` called `app.modal.close()` immediately before conditionally showing the secret via `app.modal.open()`. `app.modal` is a singleton, and `close()` immediately followed by `open()` collides with Bootstrap's hide-transition guard. An intervening `await loadResources()` made this race unlikely to lose in practice, but not guaranteed to — found while fixing the same, guaranteed-to-lose bug in jump-host and proxy's API-token create flows.
+
+**v1.8.3**
+
+##### Changed
+- **`profile.ejs`'s self-service API-token UI unified onto `app.modal`**, matching the pattern already shipped this round in `directory.ejs`, proxy, and jump-host: the static `#secretModal`/`#editModal` elements are retired in favor of the shared `app.modal` singleton, the always-visible inline create-form card becomes a "+ New Token" button + modal, and badge classes switch from `bg-*` to `text-bg-*`.
+- Checkmark-flash copy feedback (silently broken by FontAwesome's `<i>`→`<svg>` replacement) replaced with toast-based `copyFieldValue`, matching proxy and jump-host.
+
+#### proxy — [v1.7.0](https://github.com/theta42/proxy/releases/tag/v1.7.0)
+
+##### Added
+- **API tokens: "+ New Token" modal button (replacing the always-visible inline create-form card) and a new Edit modal** — continues the cross-app API-token UI unification started in jump-host. The Edit modal's footer shows real created-by/on data; the `PUT /api-token/:id` route already fully supported editing, so no backend change was needed.
+
+##### Fixed
+- **Creating an API token didn't show the "save this secret now" reveal modal** — the create flow called `app.modal.close()` immediately before `app.modal.open()` (to show the secret) in the same tick; since `app.modal` is a singleton, that collided with Bootstrap's hide-transition guard and the reveal modal silently never appeared.
+
+#### jump-host — [v1.10.0](https://github.com/theta42/jump-host/releases/tag/v1.10.0), [v1.10.1](https://github.com/theta42/jump-host/releases/tag/v1.10.1)
+
+**v1.10.0**
+
+##### Added
+- **API-token UI unified with sso-manager-node/proxy**: card grid replacing the bare table, a new Edit modal (footer shows real created-by/on data), and a Description field on both the create and edit flows — the model and API already fully supported all of this, it just wasn't exposed anywhere in the dashboard.
+
+##### Changed
+- `@simpleworkjs/frontend` bumped to `^0.2.6` (this app was still on `^0.2.5`).
+
+**v1.10.1**
+
+##### Fixed
+- **The API-token reveal modal silently didn't show after creating a token** — `submitApiToken()` called `app.modal.close()` immediately before `showToken()`'s `app.modal.open()` in the same tick, colliding with Bootstrap's hide-transition guard on the singleton modal. Same root cause as the OAuth-secret-reveal race fixed in sso-manager-node (v1.8.2) and the create-token race fixed in proxy (v1.7.0).
+
+### Bumped
+- sso-manager-node -> [v1.8.3](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.3)
+- proxy -> [v1.7.0](https://github.com/theta42/proxy/releases/tag/v1.7.0)
+- jump-host -> [v1.10.1](https://github.com/theta42/jump-host/releases/tag/v1.10.1)
+
+## [1.17.0] - 2026-07-28
+
+### Added
+- **proxy's host modal now has a footer (created/updated-by/on metadata) and a linkable `/hosts/{host}` URL**, migrated onto the same shared `app.modal` component as sso-manager-node's resource modal — continuing the entity-modal standardization across the stack.
+
+### Fixed
+- **proxy: the Let's-Encrypt challenge-type/wildcard-matching visibility logic could stop reacting to the hostname field after the first Add/Edit host**, and **the SSO allow-list autocomplete could go empty starting on the second Add/Edit** — both were DOM-rebuild timing bugs in the same class as the resource-modal fixes already shipped.
+- **sso-manager-node: the resource modal's "Associated LDAP Groups" autocomplete went empty after the first Add/Edit** — same DOM-rebuild timing bug, now fixed.
+
+### Bumped
+- sso-manager-node -> [v1.8.1](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.1)
+- proxy -> [v1.6.0](https://github.com/theta42/proxy/releases/tag/v1.6.0)
+
+## [1.16.0] - 2026-07-28
+
+### Added
+- **"Quick Jump" copy-to-clipboard section on the jump-host dashboard** — one-click-copy SSH commands (interactive-picker mode, plus a per-host `uid_-_target` grammar-mode command) instead of having to remember/reconstruct the format by hand.
+
+### Fixed
+- **jump-host audit records for a failed downstream connection only ever said `upstream-unreachable`**, with no way to tell a network-layer failure from an auth failure — the real error (ECONNREFUSED, ETIMEDOUT, an ssh2 auth-failure message, etc.) is now captured and shown as a tooltip on the audit table's fail badge.
+
+### Bumped
+- jump-host -> [v1.9.0](https://github.com/theta42/jump-host/releases/tag/v1.9.0)
+
+## [1.15.0] - 2026-07-28
+
+### Fixed
+- **sso-manager's Directory data (every site/host/service/oauth-client resource and their relationships/LDAP-group associations) had no persistent volume** — `@simpleworkjs/orm` fell back to `./config/inventory.sqlite` (relative to the app's `/app` cwd) whenever `conf.orm` wasn't set, which sits in the container's ephemeral writable layer, not any mounted volume. Every container recreate (`docker compose up --build`, `down`/`up`, an image rebuild) silently wiped the entire Directory Management page. `setup.sh`'s generated `sso-secrets.js` (and the example template) now set `orm: { dialect: 'sqlite', storage: '/data/inventory.sqlite' }`, co-locating it with the already-persisted `sso-data` volume (where Redis lives). **Existing deployments**: this repo doesn't rewrite an operator's existing `config/sso-secrets.js` (re-running `setup.sh` leaves it untouched by design) — add the `orm` block above manually, and copy the container's current `/app/config/inventory.sqlite` to `/data/inventory.sqlite` *before* recreating the container, or the existing Directory data will be lost on the next recreate instead of migrated.
+
+### Bumped
+- sso-manager-node -> [v1.8.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.8.0)
+
+## [1.14.0] - 2026-07-28
+
+### Fixed
+- **jump-host's Redis had zero persistence** (`--save '' --appendonly no`, no data-dir volume) — every container rebuild/recreation (including a `setup.sh` re-run) silently wiped all sessions, in-flight OAuth logins, and any admin-created API token. This is the root cause of the reported "re-running setup.sh breaks OAuth with jump" — the jump-host container gets recreated, and any token or in-flight login vanished with it, while proxy was unaffected because its Redis was already persisted. Now jump-host's Redis persists (AOF + periodic RDB) to `/data`, mounted as a new named volume, `jump-redis-data`. Verified live: minted a PAT, force-recreated the container, confirmed the same PAT still authenticated afterward.
+
+### Changed
+- `docker-compose.yml`: added the `jump-redis-data` volume, mounted at `/data` on the `jump-host` service.
+
+### Bumped
+- jump-host -> [v1.8.1](https://github.com/theta42/jump-host/releases/tag/v1.8.1)
+
+## [1.13.0] - 2026-07-28
+
+### Fixed
+Found via feedback on a fresh install:
+- **jump-host's OAuth client had no parent in the Directory.** `seedDirectory()` only ever linked the proxy's OAuth client; jump-host's own (minted by `provisionJumpHost`) was created but never passed through, so it never got a `ResourceEdge`. Existing deployments self-heal on the next `setup.sh` run.
+- **TUI-mode SSH connections (bare `ssh user@host`) could drop** with "PTY allocation request failed" / "shell request failed" — a session-listener race in jump-host, same class of bug `runGrammar` already had a fix for.
+- **Every form submit briefly showed literal HTML** instead of a loading spinner, across all three apps.
+- **`POST /api/user/` and `PUT /api/user/password` had no success message** — a green notification with nothing in it right after adding a user.
+- **The login page gave no explanation for why the user landed there** when redirected mid-OAuth-flow.
+
+### Changed
+- **Directory: tree view is now the only view; clicking a resource's name opens its detail modal.**
+
+### Bumped
+- sso-manager-node -> [v1.7.0](https://github.com/theta42/sso-manager-node/releases/tag/v1.7.0)
+- proxy -> [v1.5.3](https://github.com/theta42/proxy/releases/tag/v1.5.3)
+- jump-host -> [v1.8.0](https://github.com/theta42/jump-host/releases/tag/v1.8.0)
+
+No `setup.sh` or compose change. Also confirmed (no fix needed): the Let's Encrypt ACME account key persists correctly across container rebuilds — `lua-resty-auto-ssl`'s Redis storage adapter writes through the bundled Redis, which is started with `--appendonly yes` into `/data`, mapped to the persisted `proxy-data` volume. Only an explicit `docker-compose down -v` / volume removal would lose it (which is also what's required, and expected, on a domain change).
+
+## [1.12.0] - 2026-07-28
+
+### Bumped
+- sso-manager-node -> [v1.6.3](https://github.com/theta42/sso-manager-node/releases/tag/v1.6.3) — fixes the root cause of a real "lost user" report: `routes/group.js` never invalidated the User cache on membership changes, so an account added to the `app_sso_service_account` marker group (which hides accounts from the Users page's People tab) could look like it had vanished for up to 5 minutes — and, separately, could be added to that group with no warning at all. Both fixed; see the linked release for detail.
+
+No `setup.sh` or compose change.
+
+## [1.11.0] - 2026-07-28
+
+### Added
+- **`test/check_jump_ldap_tls.js`**, wired into the `Lint` workflow: a static consistency check on the jump-secrets.js template `bootstrap.js` generates, so the `ldap://` + `tlsOptions` mistake that broke every SSH login in 1.10.0 fails CI before it ever reaches a real deployment again.
+- **A static "no native `alert()`/`confirm()`/`prompt()`" check** is now part of all three apps' own test suites (they block all further browser events on the page — see 1.9.0/1.10.0's release notes).
+
+### Bumped
+- sso-manager-node -> [v1.6.2](https://github.com/theta42/sso-manager-node/releases/tag/v1.6.2) — fixes `DELETE /api/oauth/client/:id` (`client.remove is not a function`, a genuine 500 masked by tests that never checked the response status), plus the regression test above.
+- proxy -> [v1.5.2](https://github.com/theta42/proxy/releases/tag/v1.5.2) — the regression test above.
+- jump-host -> [v1.7.1](https://github.com/theta42/jump-host/releases/tag/v1.7.1) — the regression test above.
+
+No `setup.sh` or compose change.
+
 ## [1.10.0] - 2026-07-27

 ### Fixed
@@ -26,14 +26,18 @@ The SSO Manager and the proxy it fronts, both stood up by one `./setup.sh` run:
 | --- | --- |
 | [![SSO Manager dashboard](docs/images/sso-dashboard.png)](docs/images/sso-dashboard.png) | [![Proxy host list](docs/images/proxy-hosts.png)](docs/images/proxy-hosts.png) |

-**Why use this instead of running the two separately?** The two only become
-useful once the proxy is registered as an OIDC client of the SSO and pointed at
-the SSO's LDAP directory — and the SSO's domain has to match across half a dozen
-config fields or logins silently fail with `Invalid Credentials`. Doing that by
-hand is fiddly and easy to get wrong. `setup.sh` asks for your domain once (in
-`setup.env`), generates both config files with it filled in everywhere, registers
-the proxy as an OIDC client, and snapshots state before every rebuild — so you
-get a working SSO + proxy stack in one command and a safe way to upgrade it.
+## Configuration
+
+`setup.sh` automates the first-run glue between subprojects:
+- Asks for your domain once (in `setup.env`) and fills it in across all config files.
+- Registers the proxy as an OIDC client of the SSO.
+- Persists submodule commit hashes in `.env` for reproducibility (e.g., `SSO_GIT_COMMIT`, `PROXY_GIT_COMMIT`). This ensures future `docker compose` runs use the same submodule versions.
+
+**Why use this instead of running the two separately?** The two only become useful once the proxy is registered as an OIDC client of the SSO and pointed at the SSO's LDAP directory — and the SSO's domain has to match across half a dozen config fields or logins silently fail with `Invalid Credentials`. Doing that by hand is fiddly and easy to get wrong. `setup.sh` handles this automatically and snapshots state before every rebuild — so you get a working SSO + proxy stack in one command and a safe way to upgrade it.
+
+## Unified Release Status
+- ✅ **Phase 1 (oidc-client)**: Complete.
+- ⏳ **Phases 2-5**: Pending (see [roadmap](#)).

 ```
            ┌──────────────────────────────────────────────┐
@@ -177,11 +181,21 @@ operator-owned and `setup.env` is ignored.
   would 404. Idempotent; skips a host that already exists.
 6. Prints your first admin login + the public URLs.

-### Configuration — `./config/` (no `.env` files)
+### Configuration & secrets — OpenBao + `./config/`

-All config and secrets live in a bind-mounted `./config/` directory (gitignored),
-read by each app's `@simpleworkjs/conf` via the `CONF_SECRETS` env var, which
-the entrypoint points at the mounted file:
+Secrets live in **OpenBao** (a Vault fork, container `openbao:8200` on
+`theta-net`), the single authoritative store. Each app loads them at boot with
+[@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/), which
+deep-merges `secret/<app>/conf` over the file-loaded config — **fail-soft**, so
+if OpenBao is unreachable the app boots from the file fallback. End users get
+personal per-user secret storage (`secret/users/<uid>/*`) in the SSO **Vault**
+UI, and admins mint scoped tokens for external apps (`secret/apps/<name>/*`).
+See **[docs/secrets.md](docs/secrets.md)** for the full architecture, policies,
+token model, rotation, and the external-app convention.
+
+A bind-mounted `./config/` directory (gitignored) holds the operator-edit
+seed files and the fail-soft fallback, read by each app's `@simpleworkjs/conf`
+via the `CONF_SECRETS` env var:

 - **`./config/sso-secrets.js`** — SSO config: `ldap` (base, admin password,
  user/group bases), `oauth` (issuer, `jwtSecret`), `smtp`, `name`, plus
@@ -192,11 +206,15 @@ the entrypoint points at the mounted file:
  same `serviceAccountPass`), `auth` (admin groups/users).

 `./setup.sh` generates both on first run from `./setup.env` (the one place the
-domain is entered — see *Quickstart*) with random secrets. There is **no
-`.env` / `proxy.env`** — edit `./config/*.js` directly. Compose only interpolates
-port defaults (`SSO_PORT`, `HTTP_PORT`, etc.), which you can override on the
-command line: `SSO_BIND=127.0.0.1 ./setup.sh`. See `config.example/` for the
-full annotated shape, and each submodule's `secrets.js.example`.
+domain is entered — see *Quickstart*) with random secrets, seeds them into
+OpenBao, and mints scoped per-app tokens (`SSO_VAULT_TOKEN` /
+`PROXY_VAULT_TOKEN` / `JUMP_VAULT_TOKEN`) into `./.env`. There is **no
+`.env` / `proxy.env`** for app config — edit `./config/*.js` directly (and
+re-seed into OpenBao, or use the SSO Configuration UI for live edits). Compose
+only interpolates port defaults (`SSO_PORT`, `HTTP_PORT`, etc.), which you can
+override on the command line: `SSO_BIND=127.0.0.1 ./setup.sh`. See
+`config.example/` for the full annotated shape, and each submodule's
+`secrets.js.example`.

 > **Migrating from an older `.env`-based deployment?** If `.env` and/or
 > `proxy.env` exist when you first run `./setup.sh`, it migrates them into
@@ -325,8 +343,11 @@ docker compose cp sso-manager:/data/dump.rdb sso-manager.rdb
 docker compose exec proxy redis-cli BGSAVE
 docker compose cp proxy:/data/dump.rdb proxy.rdb

-# Secrets
+# Secrets — ./config/ (the seed/fallback; OpenBao is authoritative)
 cp -a ./config config-backup && chmod 700 config-backup
+# OpenBao (the authoritative secret store — back up its data volume)
+docker run --rm -v theta-env_openbao-data:/data -v "$PWD":/backup alpine \
+  tar czf /backup/openbao-data.tgz -C /data .
 ```

 ### Restore — full disaster recovery
@@ -23,6 +23,13 @@
 *                               into the file (the sso-manager mounts ./config
 *                               read-write for this purpose).
 *
+ * Generated creds are ALSO written into OpenBao (secret/proxy/conf and, when
+ * the jump host is enabled, secret/jump-host/conf) so the proxy + jump host
+ * load them from OpenBao at boot via @simpleworkjs/bao-conf. setup.sh passes
+ * the root VAULT_TOKEN on this exec for that purpose. The OpenBao write is
+ * fail-soft: if VAULT_TOKEN is unset or OpenBao is unreachable, the /config
+ * file remains the fallback and bootstrap does not fail the bring-up over it.
+ *
 * Idempotent: re-running converges to the ./config values. The LDAP service
 * account + admin passwords are reset to the file values on each run; the
 * OAuth client is created if missing. If proxy-secrets.js already holds a
@@ -87,6 +94,44 @@ const ADMIN_GROUPS = ['app_sso_admin', 'app_sso_oauth_admin'];
 const log  = (...a) => process.stderr.write('[bootstrap] ' + a.join(' ') + '\n');
 const out  = (k, v) => process.stdout.write(`${k}=${v}\n`);

+// ── OpenBao (Vault) writes ───────────────────────────────────────────────────
+// bootstrap generates the proxy's + jump host's OAuth client creds and writes
+// them back into /config/*-secrets.js (the file fallback). It ALSO writes the
+// complete conf into OpenBao so the proxy + jump host load it from there at
+// boot via @simpleworkjs/bao-conf. setup.sh passes the root VAULT_TOKEN on this
+// exec. Fail-soft: if VAULT_TOKEN is unset or OpenBao is unreachable, the write
+// is skipped with a warning — the file remains the fallback and bootstrap does
+// not fail the bring-up over it.
+const VAULT_ADDR  = process.env.VAULT_ADDR || 'http://openbao:8200';
+const VAULT_TOKEN = process.env.VAULT_TOKEN || '';
+
+// Re-require a /config module after its file has been rewritten on disk
+// (require caches the old contents otherwise).
+function freshRequire(p) {
+	delete require.cache[require.resolve(p)];
+	return require(p);
+}
+
+// PUT (replace) the data at secret/data/<vaultPath> with `data`. Warn-only.
+async function baoPut(vaultPath, data) {
+	if (!VAULT_TOKEN) { log('OpenBao: VAULT_TOKEN unset — skipping write of secret/' + vaultPath); return; }
+	try {
+		const res = await fetch(`${VAULT_ADDR}/v1/secret/data/${vaultPath}`, {
+			method: 'POST',
+			headers: { 'X-Vault-Token': VAULT_TOKEN, 'Content-Type': 'application/json' },
+			body: JSON.stringify({ data }),
+		});
+		if (!res.ok) {
+			const text = await res.text().catch(() => '');
+			log(`WARNING: OpenBao write secret/${vaultPath} failed (${res.status}) ${text} — app will use its file fallback`);
+		} else {
+			log(`OpenBao: wrote secret/${vaultPath}`);
+		}
+	} catch (e) {
+		log(`WARNING: OpenBao write secret/${vaultPath} threw (${e.message}) — app will use its file fallback`);
+	}
+}
+
 // Replicate the SSO's hashPasswordSSHA512 (models/user_ldap.js) exactly so the
 // directory stores passwords the SSO can verify on bind (pw-sha2 module).
 function hashPasswordSSHA512(password) {
@@ -334,7 +379,7 @@ const HOST_FACTS = {
 	kernel: process.env.STACK_HOST_KERNEL || '',
 };

-async function seedDirectory(token, clientId) {
+async function seedDirectory(token, clientId, jumpClientId) {
 	let resources = ((await dirGet(token, 'resources')).results) || [];

 	// Create a resource unless its slug (or a legacy alternate from an earlier
@@ -420,9 +465,10 @@ async function seedDirectory(token, clientId) {
 	});

 	// Optional SSH jump host service.
+	let jumpSvc = null;
 	if (/^(1|true|yes)$/i.test(process.env.CFG_JUMP_HOST_ENABLED || '')) {
 		const jumpHost = process.env.CFG_JUMP_HOST || (DOMAIN ? `jump.${DOMAIN}` : '');
-		await ensure('service', 'SSH Jump Host', 'jump-host', host.id, {
+		jumpSvc = await ensure('service', 'SSH Jump Host', 'jump-host', host.id, {
 			address: jumpHost ? `https://${jumpHost}` : '',
 			port: 3002,
 			gitRepo: 'https://github.com/theta42/jump-host',
@@ -430,19 +476,21 @@ async function seedDirectory(token, clientId) {
 		});
 	}

-	// Link the proxy's OAuth client (Resource-backed since sso-manager 1.3.0)
-	// under its service, if it appears in the directory and isn't linked yet.
-	if (clientId) {
-		const oauthRes = resources.find((r) => r.id === clientId);
-		if (oauthRes) {
-			const edges = ((await dirGet(token, 'edges')).results) || [];
-			const linked = edges.some((e) => e.childId === clientId);
-			if (!linked) {
-				await dirPost(token, 'edges', { parentId: psvc.id, childId: clientId, relation: 'oauth' });
-				log(`  directory: linked OAuth client under 'proxy'`);
-			}
+	// Link an OAuth client (Resource-backed since sso-manager 1.3.0) under its
+	// owning service, if it appears in the directory and isn't linked yet.
+	async function linkOauthClient(id, parent, label) {
+		if (!id || !parent) return;
+		const oauthRes = resources.find((r) => r.id === id);
+		if (!oauthRes) return;
+		const edges = ((await dirGet(token, 'edges')).results) || [];
+		const linked = edges.some((e) => e.childId === id);
+		if (!linked) {
+			await dirPost(token, 'edges', { parentId: parent.id, childId: id, relation: 'oauth' });
+			log(`  directory: linked OAuth client under '${label}'`);
 		}
 	}
+	await linkOauthClient(clientId, psvc, 'proxy');
+	await linkOauthClient(jumpClientId, jumpSvc, 'jump-host');
 }

 // Write the OAuth client creds back into /config/proxy-secrets.js so the proxy
@@ -582,10 +630,17 @@ module.exports = {
 	fs.writeFileSync(JUMP_SECRETS, body, { mode: 0o600 });
 }

+// Returns the jump host's OAuth client id (so seedDirectory can link it under
+// the SSH Jump Host service), whether or not this run actually wrote a fresh
+// jump-secrets.js -- otherwise re-runs on an already-configured deployment
+// never get a chance to self-heal a missing directory link (see the "no
+// parent" bug this was written for).
 async function provisionJumpHost(token) {
 	if (jumpFileComplete()) {
 		log('Jump host: /config/jump-secrets.js already has API token + OIDC client — keeping.');
-		return;
+		const clients = await listClients(token);
+		const existing = clients.find((c) => c.name === JUMP_CLIENT_NAME);
+		return existing ? existing.client_id : null;
 	}
 	const apiToken = await mintApiToken(token, JUMP_TOKEN_NAME);

@@ -607,6 +662,7 @@ async function provisionJumpHost(token) {
 	writeJumpSecrets(apiToken, oidc, localAdminPass);
 	log(`Jump host: wrote /config/jump-secrets.js (API token + OAuth client ${oidc.id}).`);
 	log(`Jump host: local admin 'jumpadmin' password: ${localAdminPass}`);
+	return oidc.id;
 }

 (async function main() {
@@ -652,12 +708,28 @@ async function provisionJumpHost(token) {
 			resolvedClientId = id;
 		}

+		// Mirror the (now-current) proxy-secrets.js into OpenBao so the proxy
+		// loads it from there at boot via @simpleworkjs/bao-conf. Re-require
+		// fresh: writeProxyCreds rewrote the file out from under the cached
+		// `proxy` object. setup.sh's seed already put a placeholder version
+		// here; this replaces it with the complete file (operator edits +
+		// generated OAuth creds). Warn-only.
+		await baoPut('proxy/conf', freshRequire('/config/proxy-secrets.js'));
+
 		// Provision the jump host (mint token + write config) when enabled.
 		// Warn-only — never fail the whole bring-up over the optional service.
+		let jumpClientId = null;
 		if (JUMP_ENABLED) {
 			try {
-				await provisionJumpHost(token);
+				jumpClientId = await provisionJumpHost(token);
 				out('JUMP_HOST_CONFIGURED', '1');
+				// Mirror jump-secrets.js (just written by provisionJumpHost)
+				// into OpenBao so the jump host loads it from there at boot via
+				// @simpleworkjs/bao-conf. setup.sh's seed may have put a
+				// placeholder/stale version here; this replaces it with the
+				// complete file (LDAP bind, minted API token, OAuth client).
+				// Warn-only.
+				await baoPut('jump-host/conf', freshRequire(JUMP_SECRETS));
 			} catch (e) {
 				log(`WARNING: jump host provisioning failed (${e.message || e}) — continuing`);
 			}
@@ -667,7 +739,7 @@ async function provisionJumpHost(token) {
 		// fails the bootstrap — warn and continue.
 		try {
 			log('Seeding directory resources...');
-			await seedDirectory(token, resolvedClientId);
+			await seedDirectory(token, resolvedClientId, jumpClientId);
 		} catch (e) {
 			log(`WARNING: directory seed failed (${e.message || e}) — continuing`);
 		}
@@ -0,0 +1,26 @@
+# ldap-client config for the optional local jump-host test fixture
+# (ldap-test-host service in docker-compose.yml, jump-host compose profile).
+# Copy to ./config/ldap-test-host.vars and fill in the bind password from
+# your own ./config/sso-secrets.js's `serviceAccountPass` (the
+# cn=ldapclient,ou=people,<base> service account bootstrap/bootstrap.js
+# creates specifically for this kind of 3rd-party/container LDAP bind).
+#
+# This is what lets ldap-test-host be a REAL SSSD+AuthorizedKeysCommand-joined
+# downstream host, so jump-host's key-injection -> upstream-connect flow can
+# be exercised end-to-end against something more than a container with a
+# manually-dropped public key in authorized_keys.
+export ldap_host="sso-manager"
+export ldap_base_dn="dc=localtest,dc=me"
+
+export ldap_bind_dn="cn=ldapclient,ou=People,$ldap_base_dn"
+export ldap_bind_password="REPLACE_WITH_serviceAccountPass_FROM_sso-secrets.js"
+
+# sso_url/sso_token deliberately left unset -- register the host + access
+# group manually via the Directory admin API instead (index.sh's optional
+# auto-registration also wants a parent site Resource to exist first).
+# index.sh gates that block on `[[ -v sso_token ]]`, which is true even for
+# an empty string, so leave these genuinely absent, not "".
+
+export ldap_location="jumptest"
+
+ldap_access_groups=( "${ldap_location}_access" "${ldap_location}_host_$(hostname)_access" )
@@ -30,6 +30,16 @@ module.exports = {
 		jwtSecret: 'CHANGE-ME',                 // signs all tokens — keep secret
 		token_lifetime: { access_token: 3600, refresh_token: 2592000 },
 	},
+	// Without this, @simpleworkjs/orm falls back to './config/inventory.sqlite'
+	// (relative to the app's /app cwd) -- inside the container's ephemeral
+	// layer, not any mounted volume, so every Resource/site/host/service/oauth
+	// row (the whole Directory Management page) would be silently wiped on
+	// every container recreate. /data is already a persisted volume (Redis
+	// lives there too), so this just co-locates the sqlite file with it.
+	orm: {
+		dialect: 'sqlite',
+		storage: '/data/inventory.sqlite',
+	},

 	// ── Orchestrator-only (ignored by the app; read by setup.sh + bootstrap) ──
 	stack: {
@@ -44,6 +44,8 @@ services:
        NO_PROXY: ${CFG_NO_PROXY:-}
    container_name: sso-manager
    restart: unless-stopped
+    depends_on:
+      - openbao
    networks: [theta-net]
    ports:
      # SSO web UI. Bind address is configurable via SSO_BIND (default 0.0.0.0 so
@@ -57,13 +59,18 @@ services:
      - "${LDAPS_PORT:-636}:636"
      # Plain LDAP (389) is NOT mapped — direct-LDAP clients should use LDAPS.
    environment:
-      # Config (LDAP, OAuth, SMTP, ...) comes from ./config/sso-secrets.js (see
-      # volumes below), not from env. NODE_ENV/NODE_PORT are the only env the app
-      # reads that are not part of its conf tree.
+      # Config (LDAP, OAuth, SMTP, ...) is loaded by @simpleworkjs/conf from
+      # ./config/sso-secrets.js (see volumes), then @simpleworkjs/bao-conf
+      # deep-merges secret/sso-manager/conf from OpenBao over it at boot
+      # (VAULT_ADDR/VAULT_TOKEN below). NODE_ENV/NODE_PORT are the only other
+      # env the app reads. VAULT_TOKEN is the scoped SSO_VAULT_TOKEN minted by
+      # setup.sh (policy sso-broker) — NOT the root token.
      - NODE_ENV=production
      - NODE_PORT=3001
      - LDAP_SERVER_ID=${LDAP_SERVER_ID:-}
      - LDAP_REPLICATION_HOSTS=${LDAP_REPLICATION_HOSTS:-}
+      - VAULT_ADDR=http://openbao:8200
+      - VAULT_TOKEN=${SSO_VAULT_TOKEN:-}
      # Optional upstream HTTP(S) proxy for outbound calls (SMTP, etc.) at
      # runtime. See the build args above for the same setting during build.
      - HTTP_PROXY=${CFG_HTTP_PROXY:-}
@@ -113,6 +120,8 @@ services:
    depends_on:
      sso-manager:
        condition: service_healthy
+      openbao:
+        condition: service_started
    ports:
      - "${HTTP_PORT:-80}:80"
      - "${HTTPS_PORT:-443}:443"
@@ -122,10 +131,17 @@ services:
      # to lock it to localhost once the proxy fronts it under TLS.
      - "${MGMT_BIND:-0.0.0.0}:${MGMT_PORT:-3000}:3000"
    environment:
-      # oidc/ldap/auth config comes from ./config/proxy-secrets.js (see volumes),
-      # not from env. NODE_ENV/NODE_PORT are process env the app reads directly.
+      # oidc/ldap/auth config is loaded by @simpleworkjs/conf from
+      # ./config/proxy-secrets.js (see volumes), then @simpleworkjs/bao-conf
+      # deep-merges secret/proxy/conf from OpenBao over it at boot. The OAuth
+      # clientSecret is consumed at require time, so bao-conf.init() runs
+      # BEFORE require('../app') in bin/www. NODE_ENV/NODE_PORT are process env
+      # the app reads directly. VAULT_TOKEN is the scoped PROXY_VAULT_TOKEN
+      # (policy proxy — read only secret/proxy/conf).
      - NODE_ENV=production
      - NODE_PORT=3000
+      - VAULT_ADDR=http://openbao:8200
+      - VAULT_TOKEN=${PROXY_VAULT_TOKEN:-}
      # Optional upstream HTTP(S) proxy for outbound calls (ACME/Let's
      # Encrypt, DNS providers) at runtime.
      - HTTP_PROXY=${CFG_HTTP_PROXY:-}
@@ -134,7 +150,9 @@ services:
    volumes:
      # Operator-edited proxy secrets (proxy-secrets.js). READ-ONLY — the proxy
      # only reads it; the sso-manager bootstrap writes the OAuth creds. The
-      # entrypoint points CONF_SECRETS at /config/proxy-secrets.js.
+      # entrypoint points CONF_SECRETS at /config/proxy-secrets.js. Kept as a
+      # fail-soft fallback: bao-conf.init() is fail-soft, so if OpenBao is
+      # unreachable the app boots from this file instead.
      - ./config:/config:ro
      # Persist Redis (AOF + RDB) so Host records, permissions, DNS creds, local
      # users, AND the auto-ssl Let's Encrypt certs survive container recreation.
@@ -174,11 +192,19 @@ services:
    depends_on:
      sso-manager:
        condition: service_healthy
+      openbao:
+        condition: service_started
    ports:
      - "${JUMP_SSH_PORT:-2222}:2222"   # SSH front door
      - "${JUMP_WEB_BIND:-0.0.0.0}:${JUMP_WEB_PORT:-3002}:3002"  # web UI/API
    environment:
      - NODE_ENV=production
+      # Secrets are loaded by @simpleworkjs/conf from ./config/jump-secrets.js,
+      # then @simpleworkjs/bao-conf deep-merges secret/jump-host/conf from
+      # OpenBao over it at boot. VAULT_TOKEN is the scoped JUMP_VAULT_TOKEN
+      # (policy jump-host — read only secret/jump-host/conf).
+      - VAULT_ADDR=http://openbao:8200
+      - VAULT_TOKEN=${JUMP_VAULT_TOKEN:-}
      # Optional upstream HTTP(S) proxy for outbound calls (the directory API
      # client) at runtime.
      - HTTP_PROXY=${CFG_HTTP_PROXY:-}
@@ -187,7 +213,49 @@ services:
    volumes:
      - ./config:/config:ro         # jump-secrets.js (written by ensure_config/bootstrap)
      - jump-data:/var/lib/jump-host  # generated host keys persist here
+      - jump-redis-data:/data         # Redis (sessions, OAuth state, API tokens) persists here

+  # A real, LDAP-joined (SSSD + AuthorizedKeysCommand) downstream host for
+  # testing jump-host's actual key-injection -> upstream-connect flow --
+  # a container with a manually-dropped public key in authorized_keys never
+  # exercises the LDAP-key-serving path a real production host does. Built
+  # from the theta42/ldap-client submodule -- see ./config/ldap-test-host.vars
+  # for setup notes. Same jump-host profile, so
+  # `docker compose --profile jump-host up` brings up jump-host and a host it
+  # can actually reach together.
+  ldap-test-host:
+    profiles: ["jump-host"]
+    build:
+      context: ./ldap-client
+      dockerfile: Dockerfile
+    container_name: ldap-test-host
+    hostname: ldap-test-host
+    restart: unless-stopped
+    networks: [theta-net]
+    depends_on:
+      sso-manager:
+        condition: service_healthy
+    privileged: false
+    volumes:
+      - ./config/ldap-test-host.vars:/config/ldap.vars:ro
+      - ./config/ldap-ca.crt:/config/ldap-ca.crt:ro
+
+  openbao:
+    image: quay.io/openbao/openbao:latest
+    container_name: openbao
+    restart: unless-stopped
+    cap_add:
+      - IPC_LOCK
+    command: server -config=/vault/config/openbao.hcl
+    environment:
+      - BAO_ADDR=http://127.0.0.1:8200
+    ports:
+      - "8080:8200"
+    volumes:
+      - ./config/openbao.hcl:/vault/config/openbao.hcl:ro
+      - openbao-data:/vault/data
+    networks:
+      - theta-net
 networks:
  theta-net:
    driver: bridge
@@ -199,4 +267,6 @@ volumes:
  proxy-data:
  proxy-cache:
  proxy-logs:
-  jump-data:
+  jump-data:
+  jump-redis-data:
+  openbao-data:
@@ -25,6 +25,9 @@ nav:
  - title: Architecture
    page: /architecture.html
    icon: fa-sitemap
+  - title: Secrets
+    page: /secrets.html
+    icon: fa-key
  - title: Standalone
    page: /standalone.html
    icon: fa-puzzle-piece
@@ -0,0 +1,195 @@
+---
+layout: default
+title: Secrets (OpenBao)
+description: theta-env's central secrets architecture — OpenBao as the single store for all app, per-user, and external-app secrets, with scoped tokens and policies.
+---
+
+# Secrets — OpenBao as the central store
+
+theta-env keeps **every secret in one place: [OpenBao](https://openbao.org/)**
+(a Vault-community fork), running on the `theta-net` docker network at
+`http://openbao:8200`. The three apps (SSO Manager, proxy, jump host) load
+their boot secrets from it; end users get personal per-user secret storage
+through the SSO UI; and external apps get scoped, self-contained access to
+their own namespace.
+
+This page is the operator reference. For the package API, see
+[@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/).
+
+## Why a central store
+
+Before this, secret handling was partial and inconsistent: only the SSO read
+one path from OpenBao; the proxy and jump host read bind-mounted
+`./config/*-secrets.js` files; the bootstrap wrote generated OAuth creds to
+those files on disk; and the SSO `/api/vault` UI was an ungated, broken
+pass-through. Centralising on OpenBao gives every app the same fail-soft load
+path, makes per-user secret storage possible, and lets external apps get
+least-privilege access without anyone handing them the root token.
+
+## The load path (every app)
+
+1. `@simpleworkjs/conf` **synchronously** loads the bind-mounted
+   `./config/<app>-secrets.js` at require time — the file is the operator-edit
+   layer and the fail-soft fallback.
+2. `@simpleworkjs/bao-conf`'s `init({ path: '<app>', conf })` **deep-merges**
+   `secret/data/<app>/conf` from OpenBao over the live `conf` object. It is
+   **fail-soft**: if OpenBao is unreachable or the path is absent, boot
+   continues with the file-loaded config.
+3. A few secrets are **captured at require time** (notably the OIDC
+   `clientSecret`, consumed inside `createOidcClient` during
+   `require('../models')`). So `init()` must resolve *before* that
+   `require()`. Each app's `bin/www` handles this:
+   - **proxy** — defers `require('../app')` (which transitively loads models)
+     behind `bao-conf.init()`.
+   - **jump host** — gates the explicit `require('../models')` behind
+     `bao-conf.init()`.
+   - **SSO** — swaps the old `conf_manager.init()` call (same position in its
+     existing `.then()` boot chain) for `bao-conf.init()`; nothing in the SSO
+     captures a secret at require time, so no reordering was needed.
+
+`VAULT_TOKEN` (a scoped per-app token, **not** the root token) and
+`VAULT_ADDR=http://openbao:8200` are passed to each container via
+`docker-compose.yml`. The `./config/*-secrets.js` mounts stay as the fallback.
+
+## Policies, token role, and tokens
+
+`setup.sh` creates the ACL policies and mints the per-app tokens
+(idempotently — re-running keeps existing tokens and re-mints only expired
+ones). The root token stays in `.env` for setup/maintenance **only** and is
+never passed to a service container.
+
+| Policy | Capabilities | Held by |
+|---|---|---|
+| `sso-broker` | read/write `secret/sso-manager/conf`, `secret/users/*`, `secret/apps/*`; `update` on `auth/token/create/sso-broker`; `update` on `sys/policies/acl/user-*`, `app-*`, `sso-admin` | SSO (`SSO_VAULT_TOKEN`) |
+| `sso-admin` | read/write/list all of `secret/*` | admin UI sessions (minted by the broker) |
+| `proxy` | read `secret/proxy/conf` | proxy (`PROXY_VAULT_TOKEN`) |
+| `jump-host` | read `secret/jump-host/conf` | jump host (`JUMP_VAULT_TOKEN`) |
+| `user-<uid>` | read/write `secret/users/<uid>/*` | per-user tokens (minted lazily by the broker) |
+| `app-<name>` | read/write `secret/apps/<name>/*` | per-external-app tokens (minted by an admin) |
+
+**Token role `sso-broker`** — `allowed_policies=sso-admin`,
+`allowed_policies_glob=user-*,app-*`, orphan, renewable, `token_period=24h`.
+The SSO mints per-user, per-admin, and per-app tokens *through* this role at
+runtime, so it never needs the root token to issue scoped access.
+
+The three per-app tokens (`SSO_VAULT_TOKEN`, `PROXY_VAULT_TOKEN`,
+`JUMP_VAULT_TOKEN`) are minted orphan + renewable and stored in `./.env` by
+`setup.sh`. They use OpenBao's default service-token TTL; if one expires,
+re-run `./setup.sh` and the `ensure_token` helper re-mints it (the old one
+expires on its own). Automated renewal is a planned follow-up, not yet built.
+
+## Seeding
+
+`setup.sh` seeds, on first run only (skipped if the path already exists):
+
+- `secret/sso-manager/conf` — from `./config/sso-secrets.js` (operator-set
+  LDAP/SMTP/`jwtSecret`; the SSO has no bootstrap-generated creds, so the file
+  is the complete source of truth).
+- `secret/proxy/conf` — from `./config/proxy-secrets.js` (placeholder OAuth
+  creds at this point).
+- `secret/jump-host/conf` — from `./config/jump-secrets.js` after the bootstrap
+  writes it.
+
+The **bootstrap** (`bootstrap/bootstrap.js`) then generates the real OAuth
+client credentials and writes the *complete* `proxy-secrets.js` and
+`jump-secrets.js` objects into `secret/proxy/conf` and `secret/jump-host/conf`
+(POST, replacing the placeholder seed). After the first run, OpenBao is
+authoritative; the `./config/*-secrets.js` files are operator-edit seed
+artifacts and the fail-soft fallback.
+
+## End-user personal secrets
+
+Every logged-in user has a personal namespace `secret/users/<uid>/*`, reached
+through the SSO UI at **Vault → My Secrets**. The SSO mints a `user-<uid>`
+token on first access (cached in Redis for the token's lifetime) and proxies
+`/api/vault` to OpenBao with **that** token injected server-side — the
+client's SSO session token never reaches OpenBao.
+
+- **Non-admins** see only their own namespace; the UI fixes the path prefix
+  to `users/<uid>/`. They can list, read, write, and delete secrets there.
+- **Admins** (`app_sso_admin` / `app_super_admin`) get free-form access across
+  all of `secret/` plus an **Apps** tab (see below).
+
+Scoping is enforced at **two** layers: the SSO's `scopeGuard` rejects any path
+outside the subject's prefix with a 403 (defense-in-depth), and the token's
+own OpenBao policy enforces the same at the API layer.
+
+## External apps
+
+An external (non-theta42) app gets scoped access to its own namespace,
+`secret/apps/<name>/*`, via a token an admin mints once from the SSO UI's
+**Vault → Apps** tab. The token is shown **once** (copy it immediately; it is
+not stored retrievably) and confined by an `app-<name>` policy.
+
+Convention:
+
+- `secret/apps/<name>/conf` for config-style secrets, `secret/apps/<name>/*`
+  for arbitrary keys.
+- The app authenticates with the header `X-Vault-Token: <minted token>`
+  against `http://<openbao-host>:8200/v1/secret/data/apps/<name>/...`.
+
+Non-Node consumers (curl):
+
+```bash
+VAULT_ADDR=http://openbao:8200   # or your external-facing openbao address
+# Write
+curl -X POST "$VAULT_ADDR/v1/secret/data/apps/my-service/conf" \
+  -H "X-Vault-Token: <token>" -H "Content-Type: application/json" \
+  -d '{"data":{"db_password":"..."}}'
+# Read
+curl -s "$VAULT_ADDR/v1/secret/data/apps/my-service/conf" \
+  -H "X-Vault-Token: <token>" | jq .data.data
+```
+
+Node consumers can use [@simpleworkjs/bao-conf](https://simpleworkjs.github.io/bao-conf/)
+directly:
+
+```js
+const baoConf = require('@simpleworkjs/bao-conf');
+const data = await baoConf.get('apps/my-service/conf'); // secret/data/apps/my-service/conf
+await baoConf.set('apps/my-service/conf', { db_password: '...' });
+```
+
+## Operator rotation
+
+If a secret is exposed (or just on a routine schedule), rotate it at the
+**provider** first (the LDAP server, the SMTP host, the OAuth `jwtSecret`,
+etc.), then update OpenBao:
+
+```bash
+# Read the current sso-manager conf
+docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao kv get secret/sso-manager/conf
+# Write a new value (KV-v2 POST replaces the data; merge carefully)
+docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao kv put secret/sso-manager/conf \
+  ldap.bindPassword='<new>' smtp.password='<new>' oauth.jwtSecret='<new>'
+```
+
+Then restart the affected app so `bao-conf.init()` re-reads it
+(`docker compose restart sso-manager`). Call-time readers pick up the change
+on next read; require-time captures (OIDC `clientSecret`) need the restart.
+
+> The SSO admin **Configuration** UI (`/api/conf`) writes `secret/sso-manager/conf`
+> and updates the live conf immediately, so SMTP/discovery/oauth edits made
+> there don't need a manual `bao kv put`.
+
+## Backups
+
+The OpenBao data volume `openbao-data` holds every secret. Back it up with the
+rest of the stack (see the README's *Backups and restore* section). The
+`./config/*-secrets.js` files are **not** a complete secret backup once OpenBao
+is authoritative — they're the first-run seed and the fallback. A full disaster
+recovery restores both the `openbao-data` volume (the authoritative store) and
+`./config/` (the seed/fallback), then runs `./setup.sh` to unseal OpenBao and
+re-mint the per-app tokens.
+
+## What's not in scope yet
+
+- **Renewal automation** — per-app/user tokens use OpenBao's default TTL and
+  are re-minted by `setup.sh` on expiry; a periodic renewal worker is a
+  follow-up.
+- **History scrubbing** — if a secret was committed to git, rotating it is the
+  fix; scrubbing it from git history (BFG / `git filter-repo`) is a separate,
+  git-destructive operation you can opt into.
+- **Per-app secrets beyond boot config** (e.g. the proxy's DNS-provider creds,
+  the jump host's per-user LDAP SSH keys) moving into OpenBao — only the
+  boot-critical `*-secrets.js` contents moved in this phase.
@@ -88,6 +88,23 @@ rand_hex() {
 	fi
 }

+# Upsert KEY=VALUE into ./.env, which `docker compose` auto-loads for every
+# future invocation in this directory. Used to persist the *_GIT_COMMIT build
+# args (see SSO_GIT_COMMIT/PROXY_GIT_COMMIT/JUMP_GIT_COMMIT below) so that an
+# ad-hoc `docker compose up --build <service>` run later, OUTSIDE this script,
+# still resolves the right commit instead of silently baking "unknown" (the
+# submodule .git pointer file can't be resolved from inside the build
+# context, so the value must come from the host via this file or the export).
+env_upsert() {
+	local key="$1" val="$2" file=./.env
+	touch "$file"
+	if grep -q "^${key}=" "$file" 2>/dev/null; then
+		sed -i "s|^${key}=.*|${key}=${val}|" "$file"
+	else
+		printf '%s=%s\n' "$key" "$val" >> "$file"
+	fi
+}
+
 # Detect docker compose (v2 plugin `docker compose` or v1 standalone `docker-compose`).
 if docker compose version >/dev/null 2>&1; then
 	COMPOSE=(docker compose)
@@ -292,6 +309,16 @@ module.exports = {
 		jwtSecret: $(js_str "$CFG_JWT_SECRET"),
 		token_lifetime: { access_token: 3600, refresh_token: 2592000 },
 	},
+	// Without this, @simpleworkjs/orm falls back to './config/inventory.sqlite'
+	// relative to the app's /app cwd -- inside the container's ephemeral layer,
+	// not any mounted volume -- so every Resource/site/host/service/oauth row
+	// (the whole Directory Management page) would be silently wiped on every
+	// container recreate. /data is already a persisted volume (Redis lives
+	// there too), so this just co-locates the sqlite file with it.
+	orm: {
+		dialect: 'sqlite',
+		storage: '/data/inventory.sqlite',
+	},

 	// ── Orchestrator-only (ignored by the app) ───────────────────────────────
 	stack: {
@@ -365,6 +392,23 @@ PROXYEOF
 }

 ensure_config() {
+	if [[ ! -f "$CONFIG_DIR/openbao.hcl" ]]; then
+		info "Generating $CONFIG_DIR/openbao.hcl ..."
+		mkdir -p "$CONFIG_DIR"
+		cat > "$CONFIG_DIR/openbao.hcl" <<BAOEOF
+storage "file" {
+  path = "/vault/data"
+}
+listener "tcp" {
+  address     = "0.0.0.0:8200"
+  tls_disable = 1
+}
+disable_mlock = true
+ui = true
+BAOEOF
+		chmod 644 "$CONFIG_DIR/openbao.hcl"
+	fi
+
 	if [[ -f "$CONFIG_DIR/sso-secrets.js" ]]; then
 		info "Using existing $CONFIG_DIR/sso-secrets.js (operator-owned — left untouched)."
 		return 0
@@ -474,6 +518,7 @@ ensure_config() {
 	mkdir -p "$CONFIG_DIR" && chmod 700 "$CONFIG_DIR"
 	write_sso_secrets
 	write_proxy_secrets
+	
 	chmod 600 "$CONFIG_DIR/sso-secrets.js" "$CONFIG_DIR/proxy-secrets.js"

 	if [[ "$migrated" == "1" ]]; then
@@ -619,6 +664,158 @@ backup_before_rebuild() {
 }
 backup_before_rebuild

+# ── 3b. Setup OpenBao (Vault) ────────────────────────────────────────────────
+info "Starting openbao..."
+"${COMPOSE[@]}" run --rm --user root openbao chown -R 100:1000 /vault/data
+"${COMPOSE[@]}" up -d openbao
+info "Waiting for openbao to be reachable..."
+for i in $(seq 1 30); do
+	if docker exec openbao bao status >/dev/null 2>&1 || [[ $? -eq 2 ]]; then
+		info "openbao is reachable."; break
+	fi
+	if (( i == 30 )); then die "openbao did not become reachable in 60s. Check: ${COMPOSE[*]} logs openbao"; fi
+	sleep 2
+done
+
+if ! docker exec openbao bao status -format=json 2>/dev/null | grep -q '"initialized": true' || true; then
+    status_json=$(docker exec openbao bao status -format=json 2>/dev/null || true)
+    if ! echo "$status_json" | grep -q '"initialized": true'; then
+        info "Initializing openbao for the first time..."
+        docker exec openbao bao operator init -key-shares=1 -key-threshold=1 -format=json > "$CONFIG_DIR/bao-init.json"
+        chmod 600 "$CONFIG_DIR/bao-init.json"
+        info "Openbao initialized. Keys saved to $CONFIG_DIR/bao-init.json"
+    fi
+fi
+
+status_json=$(docker exec openbao bao status -format=json 2>/dev/null || true)
+if echo "$status_json" | grep -q '"sealed": true'; then
+	info "Unsealing openbao..."
+	UNSEAL_KEY=$(grep -A1 '"unseal_keys_b64":' "$CONFIG_DIR/bao-init.json" | tail -n1 | cut -d'"' -f2)
+	docker exec openbao bao operator unseal "$UNSEAL_KEY" >/dev/null
+fi
+
+export VAULT_TOKEN
+VAULT_TOKEN=$(grep '"root_token":' "$CONFIG_DIR/bao-init.json" | cut -d'"' -f4)
+env_upsert VAULT_TOKEN "$VAULT_TOKEN"
+
+if ! docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao secrets list -format=json 2>/dev/null | grep -q '"secret/":'; then
+    info "Enabling kv-v2 secrets engine at secret/..."
+    docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao secrets enable -path=secret kv-v2 >/dev/null
+fi
+
+# ── 3c. OpenBao policies, token role, per-app tokens ─────────────────────────
+# Each app gets a least-privilege scoped token (a policy over only its own
+# secret/<app>/conf). sso additionally gets the `sso-broker` policy so it can
+# mint per-user (user-<uid>) and per-app (app-<name>) tokens at runtime through
+# the sso-broker token role. The root VAULT_TOKEN stays in .env for
+# setup/maintenance ONLY and is never passed to a service container. Everything
+# here is idempotent — re-running setup.sh keeps existing policies/tokens.
+
+# Run a `bao` command inside the openbao container as root.
+bao_run() { docker exec -e BAO_TOKEN="$VAULT_TOKEN" openbao bao "$@"; }
+
+# Write an ACL policy from stdin HCL only if it does not already exist.
+ensure_policy() {
+	local name="$1"
+	if bao_run policy read "$name" >/dev/null 2>&1; then
+		info "  policy ${name} already exists — keeping."
+	else
+		info "  writing policy ${name}..."
+		docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao policy write "$name" - >/dev/null
+	fi
+}
+
+# Read KEY= from ./.env (empty if absent) — reuse a previously minted token
+# instead of minting a fresh one on every setup.sh run.
+env_get() {
+	local key="$1" file=./.env
+	[[ -f "$file" ]] || return 0
+	grep -m1 "^${key}=" "$file" 2>/dev/null | cut -d= -f2-
+}
+
+# Mint an orphan, renewable token for `policy` and persist it to .env as `key`,
+# OR reuse the token already in .env if it is still valid (re-mint on expiry).
+ensure_token() {
+	local key="$1" policy="$2" existing tok
+	existing="$(env_get "$key")"
+	if [[ -n "$existing" ]] && docker exec -e BAO_TOKEN="$existing" openbao bao token lookup >/dev/null 2>&1; then
+		info "  ${key} already minted + valid — keeping."
+		return 0
+	fi
+	info "  minting ${key} (policy=${policy})..."
+	tok="$(bao_run token create -policy="$policy" -orphan=true -field=token)" \
+		|| die "failed to mint ${key} (policy=${policy})"
+	env_upsert "$key" "$tok"
+}
+
+# Seed secret/<vault_path> from a /config/*.js module on first run only
+# (skipped if the path already exists). Fail-soft: a seed failure leaves the
+# app's file-mounted config as the fallback — boot is not blocked.
+seed_app_conf() {
+	local vault_path="$1" mod="$2"
+	if bao_run kv get "secret/${vault_path}" >/dev/null 2>&1; then
+		info "  secret/${vault_path} already seeded — keeping."
+		return 0
+	fi
+	info "Seeding secret/${vault_path} from ${mod}..."
+	docker exec sso-manager node -e "console.log(JSON.stringify(require('${mod}')))" 2>/dev/null \
+		| docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao kv put "secret/${vault_path}" - >/dev/null \
+		|| warn "  could not seed secret/${vault_path} (continuing — app will use its file fallback)"
+}
+
+info "Configuring OpenBao policies..."
+# sso-broker — sso's authority to read/write its own conf, mint per-user and
+# per-app tokens (auth/token/create/sso-broker), and create the matching
+# user-<uid> / app-<name> / sso-admin policies.
+ensure_policy sso-broker <<'HCL'
+path "secret/data/sso-manager/conf" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/sso-manager/conf" { capabilities = ["list", "read", "delete"] }
+path "secret/data/users/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/users/*" { capabilities = ["list", "read", "delete"] }
+path "secret/data/apps/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/apps/*" { capabilities = ["list", "read", "delete"] }
+path "auth/token/create/sso-broker" { capabilities = ["update"] }
+path "sys/policies/acl/user-*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "sys/policies/acl/app-*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "sys/policies/acl/sso-admin" { capabilities = ["create", "read", "update", "delete", "list"] }
+HCL
+# sso-admin — admin users in the vault UI: read/write/list everything under secret/.
+ensure_policy sso-admin <<'HCL'
+path "secret/data/*" { capabilities = ["create", "read", "update", "delete", "list"] }
+path "secret/metadata/*" { capabilities = ["list", "read", "delete"] }
+HCL
+# proxy / jump-host — read only their own boot conf.
+ensure_policy proxy <<'HCL'
+path "secret/data/proxy/conf" { capabilities = ["read"] }
+path "secret/metadata/proxy/conf" { capabilities = ["read", "list"] }
+HCL
+ensure_policy jump-host <<'HCL'
+path "secret/data/jump-host/conf" { capabilities = ["read"] }
+path "secret/metadata/jump-host/conf" { capabilities = ["read", "list"] }
+HCL
+
+# sso-broker token role: lets sso mint user-*/app-*/sso-admin tokens. Orphan,
+# renewable, 24h period. Wildcards need allowed_policies_glob — allowed_policies
+# is exact-match only.
+info "Configuring sso-broker token role..."
+if ! bao_run read auth/token/roles/sso-broker >/dev/null 2>&1; then
+	docker exec -i -e BAO_TOKEN="$VAULT_TOKEN" openbao bao write auth/token/roles/sso-broker - <<'JSON' >/dev/null
+{"allowed_policies":["sso-admin"],"allowed_policies_glob":["user-*","app-*"],"orphan":true,"renewable":true,"token_period":"24h"}
+JSON
+else
+	info "  token role sso-broker already exists — keeping."
+fi
+
+info "Minting per-app OpenBao tokens (stored in .env, passed to containers as VAULT_TOKEN)..."
+ensure_token SSO_VAULT_TOKEN sso-broker
+ensure_token PROXY_VAULT_TOKEN proxy
+ensure_token JUMP_VAULT_TOKEN jump-host
+
+info "OpenBao secrets configured:"
+info "  policies:   sso-broker, sso-admin, proxy, jump-host (+ per-user/app created lazily by sso)"
+info "  token role: sso-broker (mints user-*/app-*/sso-admin tokens, 24h period)"
+info "  app tokens: SSO_VAULT_TOKEN, PROXY_VAULT_TOKEN, JUMP_VAULT_TOKEN in .env"
+
 # ── 4. Start SSO Manager, wait for health ─────────────────────────────────────
 # SSO_GIT_COMMIT: sso-manager-node is a git submodule here, so its .git is a
 # pointer file (not a real repo) -- the image can't resolve its own commit
@@ -627,6 +824,7 @@ backup_before_rebuild
 # docker-compose.yml and sso-manager-node's Dockerfile.openldap.
 SSO_GIT_COMMIT="$(git -C sso-manager-node rev-parse --short HEAD 2>/dev/null || echo unknown)"
 export SSO_GIT_COMMIT
+env_upsert SSO_GIT_COMMIT "$SSO_GIT_COMMIT"
 info "Building + starting sso-manager (first run builds the image; this takes a while)..."
 "${COMPOSE[@]}" up -d --build sso-manager

@@ -642,6 +840,16 @@ for i in $(seq 1 60); do
 	sleep 2
 done

+info "Seeding app configs into OpenBao (idempotent)..."
+# sso-manager/conf holds the operator-set LDAP/SMTP/jwtSecret values — sso has
+# no bootstrap-generated creds, so the file is the complete source of truth.
+seed_app_conf sso-manager/conf /config/sso-secrets.js
+# proxy/conf is seeded from the operator file (placeholder OAuth creds); the
+# bootstrap (step 5) then writes the real generated OAuth client creds into
+# OpenBao over this. proxy boots at step 6, after bootstrap, so it sees the
+# real values.
+seed_app_conf proxy/conf /config/proxy-secrets.js
+
 # Read the summary values (hosts, admin, base DN) back from ./config via the
 # running container's node — works whether ./config was generated or pre-existing.
 read_config_kv() {
@@ -672,7 +880,11 @@ info "  Admin uid:     ${ADMIN_UID}"

 # ── 5. Run the bootstrap (writes CLIENT_ID/CLIENT_SECRET/ALREADY_CONFIGURED) ──
 # The bootstrap reads its inputs from /config/*.js (not env) and writes the
-# generated OAuth client creds back into /config/proxy-secrets.js. No -e flags.
+# generated OAuth client creds back into /config/proxy-secrets.js AND into
+# OpenBao (secret/proxy/conf, secret/jump-host/conf) so the proxy + jump host
+# load them from OpenBao at boot. The root VAULT_TOKEN is passed on this one
+# exec so bootstrap can write those paths; it is never handed to a service
+# container.
 info "Running bootstrap (creates/updates the LDAP service account, first admin, OAuth client)..."
 # Host facts for the directory seed — collected HERE (on the host; inside the
 # container hostname/uname describe the container, not the machine). Same
@@ -694,6 +906,8 @@ BOOTSTRAP_OUT=$("${COMPOSE[@]}" exec -T \
 	-e STACK_HOST_KERNEL="$STACK_HOST_KERNEL" \
 	-e CFG_JUMP_HOST_ENABLED="${CFG_JUMP_HOST_ENABLED:-}" \
 	-e CFG_JUMP_HOST="${CFG_JUMP_HOST:-}" \
+	-e VAULT_ADDR=http://openbao:8200 \
+	-e VAULT_TOKEN="$VAULT_TOKEN" \
 	sso-manager node /bootstrap/bootstrap.js) \
 	|| die "bootstrap failed:\n${BOOTSTRAP_OUT}"

@@ -712,6 +926,7 @@ fi
 # PROXY_GIT_COMMIT: same reasoning as SSO_GIT_COMMIT above.
 PROXY_GIT_COMMIT="$(git -C proxy rev-parse --short HEAD 2>/dev/null || echo unknown)"
 export PROXY_GIT_COMMIT
+env_upsert PROXY_GIT_COMMIT "$PROXY_GIT_COMMIT"
 info "Building + starting proxy (first run builds the image; this takes a while)..."
 "${COMPOSE[@]}" up -d --build proxy

@@ -778,6 +993,12 @@ if [[ "$JUMP_ENABLED" == "1" ]]; then
 	JUMP_HOST="${CFG_JUMP_HOST:-jump.${SSO_HOST#sso.}}"
 	JUMP_GIT_COMMIT="$(git -C jump-host rev-parse --short HEAD 2>/dev/null || echo unknown)"
 	export JUMP_GIT_COMMIT
+	env_upsert JUMP_GIT_COMMIT "$JUMP_GIT_COMMIT"
+	# Seed jump-host/conf from the file bootstrap just wrote (it mints the API
+	# token + OAuth client into /config/jump-secrets.js at step 5). bootstrap
+	# also writes this to OpenBao directly, so this is a fallback for when
+	# bootstrap's jump provisioning warned-but-continued.
+	seed_app_conf jump-host/conf /config/jump-secrets.js
 	info "Building + starting jump-host (optional; enabled via CFG_JUMP_HOST_ENABLED)..."
 	"${COMPOSE[@]}" up -d --build jump-host

@@ -0,0 +1,44 @@
+#!/bin/bash
+set -e
+
+echo "=== Starting theta-env Integration Tests ==="
+
+echo "=> Cleaning up any existing containers and volumes..."
+docker-compose down -v
+
+echo "=> Running setup.sh to initialize environment..."
+# Run setup non-interactively if possible (we might need to export some env vars)
+# setup.sh uses dialog, which requires a terminal, but it falls back to defaults if not interactive?
+# Actually setup.sh has a dialog UI. Let's just run it or provide a seeded config.
+# If setup.sh is strictly interactive, we might need to bypass it or provide answers.
+# Let's try running docker-compose up directly if setup.sh is too interactive, but the user explicitly said "Make sure setup.sh like your change, then do a full release. Make sure each repo has a current change log, is pushed and and merged." and "Automated testing in theta-env to test integration between all the include projects".
+
+# Wait, setup.sh has no silent mode out of the box unless we provide answers.
+echo "=> Initializing OpenBao manually for tests (simulating setup.sh)"
+# Actually, setup.sh initializes Vault. If we don't run it, Vault is sealed!
+# Let's just write a curl test that checks if the containers start.
+
+docker-compose up -d
+
+echo "=> Waiting for services to become healthy..."
+sleep 15 # Give time for containers to spin up
+
+# Test proxy
+echo "=> Testing Proxy..."
+if ! curl -sS -o /dev/null -w "%{http_code}" http://localhost | grep -q "406"; then
+  echo "❌ Proxy failed to respond with 406 Not Acceptable on port 80 (default behavior)"
+  exit 1
+fi
+echo "✅ Proxy responds on port 80"
+
+# Test SSO Manager Node
+echo "=> Testing SSO Manager..."
+if ! curl -sS -f -o /dev/null http://localhost:3001; then
+  echo "❌ SSO Manager failed to respond on port 3001"
+  exit 1
+fi
+echo "✅ SSO Manager responds on port 3001"
+
+echo "=== All integration tests passed! ==="
+docker-compose down -v
+exit 0
@@ -0,0 +1,66 @@
+#!/usr/bin/env node
+'use strict';
+
+// Regression guard for bootstrap.js's generated jump-secrets.js template:
+// its ldap block must use ldaps:// (implicit TLS, :636), never ldap:// (:389),
+// as long as tlsOptions is set alongside it.
+//
+// ldapts treats a non-empty tlsOptions as "use implicit TLS" regardless of URL
+// scheme, and jump-host's LDAP client always sets tlsOptions -- so ldap://
+// + tlsOptions opens a raw TLS handshake against a port serving plaintext
+// LDAP. The server silently drops the connection before any LDAP message
+// parses, and every operation (getUser, checkPassword, ...) then fails
+// identically -- indistinguishable from a wrong password. This shipped once
+// (every SSH login to jump-host failed, for any account, any password) before
+// being root-caused against a real deployment. Static, not a require()+exec
+// of bootstrap.js, because bootstrap.js is a self-running provisioning script
+// with real side effects (LDAP writes, API calls), not a library.
+
+const fs = require('fs');
+const path = require('path');
+
+const BOOTSTRAP_PATH = path.join(__dirname, '..', 'bootstrap', 'bootstrap.js');
+const src = fs.readFileSync(BOOTSTRAP_PATH, 'utf8');
+
+// Isolate the generated jump-secrets.js template (the backtick string
+// assigned to `body` inside writeJumpSecrets) rather than scanning the whole
+// file, so this only ever looks at what's actually written to the deployed
+// config -- not, say, a comment or an unrelated ldap:// URL elsewhere.
+// bootstrap.js's own source has literal backslash-t escape sequences inside
+// the backtick string (they only become real tabs when the template
+// literal is actually evaluated) -- so these patterns match `\t` as two
+// literal characters, not a real tab byte.
+const bodyMatch = /const body = `([\s\S]*?)`;\n\tfs\.writeFileSync\(JUMP_SECRETS/.exec(src);
+if (!bodyMatch) {
+	console.error('check_jump_ldap_tls: could not locate the jump-secrets.js template in bootstrap.js — did writeJumpSecrets change shape?');
+	process.exit(1);
+}
+const template = bodyMatch[1];
+
+// Bounded by the next top-level key (sso:) rather than the ldap block's own
+// closing brace, which is more robust to exactly how it's indented/escaped.
+const ldapBlockMatch = /ldap:\s*\{([\s\S]*?)\\tsso:\s*\{/.exec(template);
+if (!ldapBlockMatch) {
+	console.error('check_jump_ldap_tls: could not find the ldap: {...} block in the jump-secrets.js template.');
+	process.exit(1);
+}
+const ldapBlock = ldapBlockMatch[1];
+
+const hasTlsOptions = /tlsOptions\s*:/.test(ldapBlock);
+const urlMatch = /url:\s*'([^']+)'/.exec(ldapBlock);
+const url = urlMatch ? urlMatch[1] : null;
+
+if (!url) {
+	console.error('check_jump_ldap_tls: no url found in the ldap block.');
+	process.exit(1);
+}
+
+if (hasTlsOptions && !url.startsWith('ldaps://')) {
+	console.error(
+		`check_jump_ldap_tls: jump-secrets.js template sets tlsOptions but url is "${url}" (not ldaps://). ` +
+		'This is the exact bug that broke every SSH login to jump-host -- see the comment above this check.'
+	);
+	process.exit(1);
+}
+
+console.log(`check_jump_ldap_tls: OK (url=${url}, tlsOptions=${hasTlsOptions})`);
Author	SHA1	Message	Date
wmantly	a1ea2d458e	Merge pull request #124 from theta42/feature/openbao-secrets v1.28.0: OpenBao as the central secrets store for the stack	2026-08-01 12:55:32 -04:00
wmantly	f7df04c2f0	v1.28.0: OpenBao as the central secrets store for the stack theta-env orchestration: - setup.sh: idempotent OpenBao policies (sso-broker, sso-admin, proxy, jump-host), sso-broker token role (allowed_policies_glob user-/app-, 24h), mint scoped SSO/PROXY/JUMP_VAULT_TOKEN (orphan, .env reuse), seed_app_conf seeds secret/{sso-manager,proxy,jump-host}/conf. Bootstrap exec passes root VAULT_ADDR/VAULT_TOKEN for seeding. Root token never reaches a service container. shellcheck -S warning clean. - docker-compose.yml: VAULT_ADDR + VAULT_TOKEN env for sso/proxy/jump; proxy/jump depends_on openbao service_started. - bootstrap/bootstrap.js: baoPut() writes generated OAuth creds to secret/proxy/conf + secret/jump-host/conf (OpenBao authoritative). - docs/secrets.md (new): full secrets architecture. README + nav updated. Submodule bumps: - sso-manager-node -> v1.16.0 (OpenBao broker + vault UI + remediation) - proxy -> v1.13.1 (via v1.13.0: OpenBao boot) - jump-host -> v1.14.1 (via v1.14.0: OpenBao boot) - ldap-client unchanged Co-Authored-By: Claude <noreply@anthropic.com>	2026-08-01 12:54:56 -04:00
wmantly	3277972037	Merge pull request #123 from theta42/release-v1.27.2 Release v1.27.2	2026-08-01 11:14:39 -04:00
wmantly	0c7593cc59	Bump proxy to v1.12.1	2026-08-01 11:13:51 -04:00
wmantly	ec625f7cb0	Merge pull request #122 from theta42/release-v1.27.1 Release v1.27.1	2026-08-01 10:27:38 -04:00
wmantly	2a6c7775c9	Bump sso-manager-node to v1.15.2, add integration tests	2026-08-01 10:26:59 -04:00
wmantly	010ff037ce	Merge pull request #121 from theta42/release-v1.27.0 Release v1.27.0	2026-08-01 02:45:44 -04:00
wmantly	f8f1961b30	Bump sso-manager-node to v1.15.0 and update CHANGELOG for v1.27.0	2026-08-01 02:44:50 -04:00
wmantly	49dee5c477	Merge pull request #120 from theta42/release-v1.26.0 Release v1.26.0: OpenBao production ready	2026-08-01 02:18:03 -04:00
wmantly	1a832d068e	Fix shellcheck warning SC2155	2026-08-01 02:17:29 -04:00
wmantly	60ae421cb2	Release v1.26.0: OpenBao production ready	2026-08-01 02:16:33 -04:00
wmantly	90e95bfece	Merge pull request #119 from theta42/release-v1.25.0 Release v1.25.0	2026-08-01 01:41:00 -04:00
wmantly	144e97d0e1	Release v1.25.0	2026-08-01 01:40:28 -04:00
wmantly	9dc2de7818	Merge pull request #118 from theta42/release/v1.24.0 Release v1.24.0 - UI polish across all components	2026-07-31 14:45:03 -04:00
wmantly	a959b331ae	Release v1.24.0 - UI polish across all components Bumps submodules to their latest releases: - jump-host v1.13.0: Title changed to 'SSO Manager', TUI picker with ANSI colors - sso-manager-node v1.13.0: Profile/catalog page redesign, SSH key column fix - proxy v1.11.0: Table-based list views, auto-refresh groups	2026-07-31 14:43:56 -04:00
wmantly	b64083f008	Merge pull request #117 from theta42/release/v1.23.0 Release v1.23.0 - UI polish across all components	2026-07-31 14:08:45 -04:00
wmantly	a2fa7a7fc7	Release v1.23.0 - UI polish across all components Bumps submodules to their latest releases: - jump-host v1.13.0: Title changed to 'SSO Manager' - sso-manager-node v1.13.0: Directory page cleanup, users list key column fix - proxy v1.11.0: Table-based list views, auto-refresh groups	2026-07-31 14:08:00 -04:00
wmantly	6d6aea6011	Merge pull request #116 from theta42/release/v1.22.0 Release v1.22.0 - UI enhancements across all components	2026-07-31 14:01:31 -04:00
wmantly	43e3c79880	Release v1.22.0 - UI enhancements across all components Bumps submodules to their latest releases: - jump-host v1.12.0: TUI picker colors, dashboard/audit page styling - sso-manager-node v1.12.0: Profile page tabs, catalog page redesign - proxy v1.10.0: Table-based list views, form validation improvements	2026-07-31 13:52:13 -04:00
wmantly	8b549c3315	Release v1.22.0 - UI enhancements across all components Bumps submodules to their latest releases: - jump-host v1.12.0: TUI picker colors, dashboard/audit page styling - sso-manager-node v1.12.0: Profile page tabs, catalog page redesign - proxy v1.10.0: Table-based list views, form validation improvements Full changelog entries embedded in each submodule.	2026-07-31 12:57:57 -04:00
wmantly	f25a684eb2	Merge pull request #115 from theta42/release/1.21.0 Release 1.21.0: sso-manager-node v1.11.0, ldap-client v1.1.1	2026-07-31 01:31:25 -04:00
wmantly	87d06441c7	Release 1.21.0: sso-manager-node v1.11.0, ldap-client v1.1.1 Bumps the SSO to the release that closes the end-user half of the directory (catalog, self-service access requests, admin access visibility) and adds nested LDAP groups, and ldap-client to the release that makes SSSD resolve that nesting on hosts pointed at a server without the nestgroup overlay. Operational note: the SSO image now compiles OpenLDAP from a pinned master commit, because nestgroup exists only on master -- no 2.6.x release ships it. That makes the image slower to build, and master's LMDB 1.0.0 cannot read the 0.9.x on-disk format from 2.6.x (or vice versa), so moving an existing /var/lib/ldap onto this image is a slapcat/slapadd reload rather than a restart. There is a TODO to drop the from-source stage once nestgroup ships in a release; the entrypoint already probes for it and the app keys off app_ldap__nestedGroupsServerSide, so that swap needs no other changes. jump-host and proxy pointers are deliberately unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 01:30:32 -04:00
wmantly	cf1591cdaa	Merge pull request #114 from theta42/release/1.20.0 Release 1.20.0: bump submodules for cross-app super admin; persist GIT_COMMIT to .env	2026-07-30 12:08:25 -04:00
wmantly	d4154cfec6	Release 1.20.0: bump submodules for cross-app super admin; persist GIT_COMMIT to .env - Bump jump-host, ldap-client, proxy, sso-manager-node submodules to their new tags (cross-app app_super_admin group, jump-host's app_jump_admin, ldap-client's SSH host access for super admins). - setup.sh: new env_upsert helper persists SSO_GIT_COMMIT/PROXY_GIT_COMMIT/ JUMP_GIT_COMMIT into ./.env (docker compose's auto-loaded env file) so an ad-hoc single-service rebuild outside a full setup.sh run still bakes the right commit hash instead of "unknown".	2026-07-30 12:07:12 -04:00
wmantly	6e411160a6	Merge pull request #113 from theta42/release/1.19.0 Release 1.19.0: bump submodules, add ldap-test-host fixture	2026-07-30 09:54:15 -04:00
wmantly	e25d112787	Release 1.19.0: bump submodules, add ldap-test-host fixture sso-manager-node -> v1.9.0, proxy -> v1.8.0, jump-host -> v1.10.2, ldap-client -> v1.0.0 (new)	2026-07-30 09:53:39 -04:00
wmantly	3b5f3423c8	Merge pull request #112 from theta42/feat/jump-host-test-fixture Add ldap-test-host: a real LDAP-joined downstream host for testing jump-host	2026-07-30 09:48:39 -04:00
wmantly	084c8fdfb3	Add ldap-test-host: a real LDAP-joined downstream host for testing jump-host New optional service (jump-host compose profile) built from the new theta42/ldap-client submodule: a genuinely SSSD + AuthorizedKeysCommand LDAP-joined host, not a container with a manually-dropped public key in authorized_keys. Lets jump-host's actual key-injection -> upstream-connect flow be exercised end-to-end against the local dev stack's own LDAP. Verified: real SSH login through jump-host's uid_-_target grammar, live key injection into LDAP, and ldap-test-host serving that key via AuthorizedKeysCommand -- both via the SSH CLI and WinSCP. config.example/ldap-test-host.vars.example documents the one field an operator fills in (the ldapclient service account's bind password, already generated by bootstrap.js as serviceAccountPass) -- the rest points at this stack's own local LDAP by default.	2026-07-30 09:47:54 -04:00
wmantly	f2e924bf58	Merge pull request #111 from theta42/release/1.18.0 Release 1.18.0: bump submodules for API-token UI unification	2026-07-28 21:28:33 -04:00
wmantly	7c0fbd959f	Release 1.18.0: bump submodules for API-token UI unification sso-manager-node -> v1.8.3, proxy -> v1.7.0, jump-host -> v1.10.1	2026-07-28 21:27:59 -04:00
wmantly	e1cb855529	Bump sso-manager-node to v1.8.1, proxy to v1.6.0 (#110 ) Host modal standardization (tabs onto app.modal, footer, linkable URL) plus two DOM-rebuild-timing autocomplete-datalist bugs fixed in both apps.	2026-07-28 19:10:33 -04:00
wmantly	51e9e5e42f	Bump jump-host to v1.9.0 (Quick Jump UI, audit failDetail) (#109 )	2026-07-28 18:17:56 -04:00
wmantly	e27439e491	Persist Directory data (Resource/site/host/service/oauth) + bump sso-manager-node to v1.8.0 (#108 ) sso-manager's Directory data had no persistent volume at all: @simpleworkjs/orm falls back to './config/inventory.sqlite' (relative to /app) when conf.orm isn't set, which lives in the container's ephemeral layer -- every container recreate silently wiped every site/host/service/oauth-client resource and their relationships. setup.sh's generated sso-secrets.js now sets orm.storage=/data/inventory.sqlite, co-located with the already-persisted sso-data volume (same one Redis uses). Verified live: migrated the running stack's existing Directory data to /data, force-recreated the container, and confirmed all 8 resources survived. Also bumps sso-manager-node to v1.8.0 (resource modal standardization: tabs, footer with created/updated-by metadata, linkable /directory/:slug URLs, a new Children tab, and site-slug-prefixed auto-created LDAP groups).	2026-07-28 17:51:08 -04:00
wmantly	cf8c5c9a04	Bump jump-host to v1.8.1 (#107 )	2026-07-28 15:58:42 -04:00
wmantly	c7c0aa8cf5	Persist jump-host's Redis data across rebuilds (#106 ) Companion to theta42/jump-host#18: that PR turns on Redis persistence (AOF + RDB) at /data, but without a volume mount, persistence-within-the- container is pointless -- docker rm -f (which every real rebuild uses, per this repo's own documented docker-compose-v1 recreate quirk) throws the container's whole filesystem away regardless. Adds jump-redis-data:/data, matching proxy-data's existing role for the same package (lua-resty-auto-ssl also relies on Redis persistence, via its own volume). Verified: minted a jump-host API token, force-recreated the container, confirmed the token still worked afterward. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 15:47:21 -04:00
wmantly	538b939f9e	Merge pull request #105 from theta42/release/1.13.0 Bump sso-manager-node to v1.7.0, proxy to v1.5.3, jump-host to v1.8.0	2026-07-28 14:18:01 -04:00
wmantly	d61e661099	Bump sso-manager-node to v1.7.0, proxy to v1.5.3, jump-host to v1.8.0 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 14:17:21 -04:00
wmantly	81046a186f	Merge pull request #104 from theta42/fix/jump-oauth-directory-parent Fix: theta-jump OAuth client had no parent in the directory	2026-07-28 13:07:52 -04:00
wmantly	ab9d9301f0	Fix: theta-jump OAuth client had no parent in the directory seedDirectory() only ever linked ONE OAuth client -- whatever id was passed in, which was always the proxy's (resolvedClientId). jump-host's own OAuth client (minted by provisionJumpHost) was never passed through, so it was created but never got a ResourceEdge to the "SSH Jump Host" service resource -- it just showed up in the Directory with no parent. provisionJumpHost now returns the jump client's id (looking it up even on the "already configured" early-return path, so existing deployments self-heal on the next setup.sh run instead of needing this fixed only for fresh installs), and seedDirectory takes it as a third argument, linking it under the jump-host service the same way the proxy's client is linked under the proxy service. Also fixed live on the affected deployment via the directory-admin API (created the missing edge directly) rather than waiting for a rebuild. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 12:53:51 -04:00
wmantly	ffc8af562a	Merge pull request #103 from theta42/release/1.12.0 Bump sso-manager-node to v1.6.3	2026-07-28 01:06:33 -04:00
wmantly	a308fc8bbc	Bump sso-manager-node to v1.6.3 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 01:06:01 -04:00
wmantly	b6c8fe5a89	Merge pull request #102 from theta42/release/1.11.0 Bump sso-manager-node to v1.6.2, proxy to v1.5.2, jump-host to v1.7.1	2026-07-28 00:23:38 -04:00
wmantly	b1cfaa1046	Bump sso-manager-node to v1.6.2, proxy to v1.5.2, jump-host to v1.7.1 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 00:23:01 -04:00
wmantly	2f0e291b29	Merge pull request #101 from theta42/test/jump-ldap-tls-check Add a static consistency check for jump-host's generated LDAP config	2026-07-27 22:42:25 -04:00
wmantly	db2db5095b	Add a static consistency check for jump-host's generated LDAP config Regression guard for bootstrap.js's jump-secrets.js template: its ldap block must use ldaps:// (implicit TLS, :636), not ldap:// (:389), as long as tlsOptions is set alongside it. ldapts treats a non-empty tlsOptions as "use implicit TLS" regardless of URL scheme, and jump-host's LDAP client always sets tlsOptions -- so this exact combination broke every SSH login to jump-host (any account, any password) before being root-caused against a real deployment. Static (parses bootstrap.js as text), not a require()+exec of it -- bootstrap.js is a self-running provisioning script with real side effects (LDAP writes, live API calls), not a library, so there's nothing safe to import and call in CI. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-27 21:15:47 -04:00