Let a service require its callers to be authenticated

[rbardaji]

The proxy at /services/redirect/{name} has no authentication of its own. Whoever can reach the Endpoint can reach every registered service through it, whatever the service's own access rules are.

A service can now ask for callers to be authenticated first:

curl -X POST http://localhost:8002/services \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"service_name":"private-service", ..., "extras":{"requires_auth":"true"}}'

From then on the Endpoint validates the caller's bearer token — the same validation as everywhere else — before forwarding anything.

A service without that extra is exactly as open as before, which is every service registered until now. Per service rather than a global switch, so an Endpoint can offer public and protected services side by side.

What it is, and is not

It checks that the caller holds a token this Endpoint can validate. It is authentication, not authorization: it does not look at groups or roles. A service needing finer rules still applies them itself, and can — the proxy forwards the Authorization header, so the token reaches it.

That forwarding is worth stating plainly, and the diagram now does: whoever registers a service receives the tokens of everyone who reaches it through the proxy. Registering requires a writer role, so it is not open to anonymous callers, but it matters when pointing a service at somewhere you do not control.

Verified

Against a live Endpoint, with a service registered carrying the extra:

Request	Result
Protected, no token	401 This service requires authentication. Provide a bearer token., WWW-Authenticate: Bearer
Protected, valid token	200, the service's own response
Protected, subpath, no token	401
Open service, no token	200, unchanged
Unknown service	404, unchanged

Plus 23 new unit tests covering the extra's spellings, the gate on its own — including that a 502 from the authentication service is not rewritten into a 401 — and both proxy routes, asserting the service is never contacted when the caller is refused. 1230 tests in total, black --check . and flake8 clean.

Found while testing, not fixed here

A token that is simply wrong answers 502, everywhere in the API, not just here: the authentication service answers 400 for a token it rejects and get_current_user maps unrecognised statuses to 502. So a mistyped token is reported as the authentication service being broken. Filed as #234.