ilpanich / axiam-java-sdk / 34778535764

92%

push

github

feat(pki,auth): sign_csr management op and a session-less passkey setup pair (#93)

F-1 fan-out (Java): re-vendors CONTRACT.md/openapi.json/management-registry.json/
proto/ from ilpanich/axiam@3d5b279 (contract 1.45) and lands the two items
that landed server-side this wave.

C-1 (mechanical): `python3 scripts/gen_management.py` picks up the new
`certificates.sign_csr` -> `POST /api/v1/certificates/sign-csr` entry and
regenerates `CertificatesApi.signCsr`, the `SignCertificateCsrRequest`
model and `ManagementSurfaceGeneratedTest` — the operation count moves
159 -> 160, entirely generator output, nothing hand-edited. Per §27.5 the
response is the existing `Certificate`, not `GeneratedCertificate`: a
CSR-signed certificate has no private key for AXIAM to return, so a
mandatory `private_key_pem` field would have to lie on every response.
Added `signCsrReturnsCertificateWithNoPrivateKeyField`, a reflective model
test asserting the return type carries no private-key-shaped field and
nothing wrapped in `Sensitive<T>`.

M-3 (mirror): `webauthnSetupRegisterStart`/`webauthnSetupRegisterFinish`
plus their `*Async` companions, the WebAuthn twins of
`mfaSetupEnroll`/`mfaSetupConfirm` for a forced first-login enrolment. Per
CONTRACT.md §24.1 this pair takes no session — the setup token in the
request body is the only credential — and an SDK MUST NOT attach its own
session credential even when one is configured. `webauthnSetupRegisterFinish`
mirrors `mfaSetupConfirm`'s adoption exactly (§25.2 rule 2): same
`onCredentialChange()` + `authenticatedFrom()` tail, same 403-message
surfacing as `webauthnRegisterFinish` (generalised `registerFinishError` to
take the operation name rather than duplicating it).

Enforcing "no session credential" turned out to need two fixes, not one:

- `AuthInterceptor` gained a same-shaped path exclusion to the one it
  already has for the refresh endpoint, withholding Authorization and CSRF
  headers. Cookies needed a different mechanism:... (continued)

1892 of 2287 branches covered (82.73%)

Branch coverage included in aggregate %.

6000 of 6302 relevant lines covered (95.21%)

4.91 hits per line