feat(pam-access): add POST /pam/whoami so a server can read its own id

[guimard]

Closes the migration gap #86 opens: /pam/bastion-token's probe: true mode was the only way for an enrolled server to read the per-device id the portal gave it, and removing the endpoint took that with it.

Why the id matters

It is not a diagnostic. The per-device id is the bastion=<id> written into every hop certificate's key-id, and a backend's AuthorizedPrincipalsCommand matches it against /etc/open-bastion/allowed_bastions. It decides which bastion may reach which backend. open-bastion/scripts/ob-bastion-id reads it, and both deployment paths (local-test/deploy-shell.sh:57, deploy-ansible.sh:73) feed it straight into that allowlist.

Nothing else answered the question

Checked each candidate rather than assumed, and t/20 now pins all three as tripwires so the claim cannot quietly rot:

• /pam/authorize returns no caller identity.
• /pam/heartbeat returns none either.
• /oauth2/introspect answers active, aud, exp, client_id, scope, nbf, iat, sub, iss, token_type — it does not export private session keys, and _deviceId is one.
• The id is a sha256_hex('pam-device-id:' . session_id) computed portal-side; a bastion cannot derive it locally.

What this restores, and what it does not

The one part of the probe worth keeping, and nothing else. It signs no JWT — the probe signed one even when the user lookup had failed, which is why the endpoint went — writes no session, and leaves _pamSeen alone so running it does not look like a heartbeat. That last point is why this is a new route rather than a field bolted onto /pam/heartbeat: heartbeat slides the refresh token's expiry, stamps _pamLastSeen and mints an access token, and it needs the refresh token, which ob-bastion-id does not read today.

It goes through the standard caller gate, so pamAccessAllowedRps (#50) and request signing (#81) apply to it for free instead of being reimplemented. t/20 pins both.

POST /pam/whoami        Authorization: Bearer <server token>        {}

{ "server_id": "9f86d081...", "bastion_id": "9f86d081...",
  "client_id": "pam-access", "server_group": "bastion" }

server_id is canonical (the audit trail's vocabulary). bastion_id is the same value under the name the probe used, so ob-bastion-id only has to change its URL. server_group appears only when pamAccessServerGroups maps the client_id — never the legacy body-declared fallback: a server asking who it is must not be told back what it claimed.

POST rather than GET because every sibling endpoint is POST and GET /pam/* is already claimed by the catch-all that redirects browsers to the portal.

Notes

• The per-device id needs oidcRPMetaDataOptionsDeviceOwnership = organization. Without it there is nothing per-device to report and the answer falls back to the client_id — which an allowlist must not be keyed on, since every machine of the project shares it. Documented in the README.
• Stacked on feat(pam-access): verify X-Signature-256 / X-Timestamp / X-Nonce #93 to keep out of the CHANGELOG conflicts; say the word and I will rebase it onto main if you would rather merge it early.
• Still to do on the open-bastion side: point ob-bastion-id at the new URL, and fix tests/test_integration_docker.sh, which tolerates a 403 but not a 404.

29 assertions in t/20; the four affected suites pass.

https://claude.ai/code/session_01GfBG36HfzjGy8W9rJQbxBL