Pass Squid 7’s Authenticated Username to an ICAP Service

An ICAP service can receive the authenticated identity known to Squid, but both sides need to agree on how that identity is carried. Naming a header alone does not enable username forwarding.

For an existing Squid 7 setup with ICAP support and client authentication, the relevant settings can be:

adaptation_send_username on
icap_client_username_header X-Authenticated-User
icap_client_username_encode off

This supplements the existing ICAP service, adaptation rules and proxy access configuration. It does not create authentication or an adaptation service.

Match the service’s input

Squid’s default username header is X-Client-Username. If the adapter expects X-Authenticated-User, either change Squid’s configured name as above or configure the adapter to read the default. Header-name matching follows HTTP’s case-insensitive rules.

The encoding must agree too. With icap_client_username_encode enabled, Squid Base64-encodes the value. The service needs to decode that representation rather than treat it as a different username.

This is metadata on the ICAP exchange between Squid and its service. It is not an instruction to send a user identity header to every destination website.

If the service still reports an IP address

Confirm that the transaction actually has an authenticated username at Squid, that username forwarding is enabled, and that the service reads the configured header. An adapter’s fallback to a client address does not establish that Squid authentication failed; the handoff itself may be missing or misnamed.

Treat this identity as trusted only across the controlled Squid-to-adapter path. These directives are version-specific: the configuration reference lists them for Squid 7 and earlier lines, and marks them unavailable in Squid 8.