ilpanich / axiam-csharp-sdk / 34778544230

94%

push

github

feat(certificates,webauthn): CSR-signed certificates and passkey first-factor setup (contract 1.45) (#88)

F-1 fan-out of mfa-first-login-and-csr-issuance-plan.md's C-1 and M-3 for this
SDK: re-vendors CONTRACT.md/openapi.json/management-registry.json/proto/ from
ilpanich/axiam@3d5b279 and adds the two operations that landed on the server
side of that plan.

C-1 (mechanical): `ManagementApi.Certificates.SignCsrAsync`, generated by
`scripts/gen_management.py` from the vendored registry/spec —
`POST /api/v1/certificates/sign-csr`, taking the new `SignCertificateCsrRequest`
and returning the existing `Certificate`, not `GeneratedCertificate`: there is
no private key to return on this path, and no field to leave empty. The §27.9
surface count moves 159 -> 160 in `ManagementSurfaceGeneratedTests`. A new
`ManagementSemanticsTests` case asserts, reflectively, that `Certificate`
carries no private-key property at all, on top of the generated round-trip
case.

M-3 (mirror): `AxiamClient.WebauthnSetupRegisterStartAsync` /
`WebauthnSetupRegisterFinishAsync`, the WebAuthn twins of
`MfaSetupEnrollAsync`/`MfaSetupConfirmAsync` — a passkey or security key as
the first factor at forced MFA setup, instead of TOTP only. Both take the
login's setup token as their sole credential and, per CONTRACT.md §24.1, MUST
NOT carry this client's own session credential even when one is configured.
Reusing the existing `_httpClient` could not guarantee that: its inner
`HttpClientHandler` owns `_cookieContainer` directly, so an outer handler has
no way to suppress the Cookie header it derives from the jar on a per-request
basis. Instead `AxiamClient` now owns a second, permanently cookie-free
`HttpClient` (same TLS/mTLS policy, its own empty `CookieContainer`) used only
by these two calls. A successful `WebauthnSetupRegisterFinishAsync` still
adopts the session it creates exactly as `MfaSetupConfirmAsync` does: the new
`CookieJarBridge` (unit tested on its own) copies whatever the an... (continued)

2109 of 2435 branches covered (86.61%)

Branch coverage included in aggregate %.

72 of 78 new or added lines in 5 files covered. (92.31%)

8010 of 8314 relevant lines covered (96.34%)

236.38 hits per line