ilpanich / axiam-rust-sdk / 31607011223

94%

push

github

feat(uma): wire §20.3 challenge emission into the §11 route guard, plus the example pair (#52)

X2 step 4 asks for "middleware sugar: on 403, emit the WWW-Authenticate: UMA
challenge with a fresh ticket (spec §3.2), client-side helper consumes it". The
§20 fan-out shipped the two helpers; this ships the wiring and the example pair
the X2 acceptance criterion names.

RequireAccess::with_uma_challenge takes a UmaChallenger (realm, as_uri, PAT).
On denial the guard mints a ticket for the action it just refused and returns
the challenge alongside the 403. AuthzGuardError gains DeniedWithChallenge,
which carries the already-formatted header value: minting is a wire call and
ResponseError::error_response is synchronous, so the ticket has to be in hand
before the response is rendered.

Two properties the tests exist to hold:

- Opt-in. Emitting a challenge means minting a credential — a Protection API
  call and a live ticket, on a path the caller did not request. A guard that did
  that on every denial by default would be a denial-of-service amplifier
  pointed at its own authorization server. An allow mints nothing, and a guard
  with no challenger behaves exactly as it did before.
- Failure is not escalation. If minting fails, the denial still surfaces as a
  plain 403 with no challenge. The caller was going to be refused either way;
  letting a Protection API outage turn a deny into a 500 would hand the outage a
  second consequence, and letting it turn into an allow would be a security bug.

The ticket asks for the AXIAM *action* as its UMA scope — the same mapping the
server uses, so a deny rule vetoes the resulting RPT exactly as it vetoed the
check that produced the ticket.

The example pair is runnable: the resource server mints a PAT, registers a
resource and guards a route; the client catches the refusal, parses the
challenge, and then makes the as_uri trust decision *explicitly* before
exchanging. That last step is the point of §20.3 — the as_uri... (continued)

58 of 58 new or added lines in 1 file covered. (100.0%)

5270 of 5563 relevant lines covered (94.73%)

31.21 hits per line