[Dextheking1]

fetchSAMLMetadata used http.DefaultClient and io.ReadAll with no bounds. A metadata_url that serves a huge body, or one that never finishes responding, ties up the fetch until the remote side gives up and reads unbounded memory. This also runs on the ACS path when cached metadata goes stale, so it does not need an admin call to trigger, just a provider whose metadata endpoint misbehaves.

Fix: dedicated client with a 10s timeout (same as OIDC discovery fetches) and a 5 MiB cap on the response body with an explicit error past the cap. Real single-IdP metadata is far below the cap.

Tests: new internal tests in ssoadmin_fetch_test.go cover the happy path, an oversized body, and a server that never responds.

[hf]

This should use a timeout context, not a new client.

[hf]

If the data is compressed (usually is) this protects from nothing. There's a better way, reading the Content-Length and rejecting first, then using a LimitReader and rejecting if Content-Length doesn't match (illegal HTTP).

[Dextheking1]

done both. timeout now comes from a context on the request with DefaultClient, no separate client. size check now rejects on Content-Length first, then LimitReader on the decoded body, then rejects if the read length does not match Content-Length. gzip responses skip the length match since the transport decompresses them. added a gzip test, the four fetch tests pass locally.