En ICAP-tjänst kan ta emot den autentiserade identitet som Squid känner till, men båda parter måste komma överens om hur identiteten överförs. Att bara namnge ett huvud aktiverar inte vidarebefordran av användarnamnet.

För en befintlig Squid 7-installation med ICAP-stöd och klientautentisering kan de relevanta inställningarna vara:

adaptation_send_username on
icap_client_username_header X-Authenticated-User
icap_client_username_encode off

Detta kompletterar den befintliga ICAP-tjänsten, anpassningsreglerna och proxyåtkomstkonfigurationen. Det skapar inte autentisering eller en anpassningstjänst.

Anpassa till tjänstens indata

Squids standardhuvud för användarnamn är X-Client-Username. Om adaptern förväntar sig X-Authenticated-User ändrar du Squids konfigurerade namn enligt ovan eller konfigurerar adaptern att läsa standarden. Matchning av huvudnamn följer HTTP:s regler utan skillnad mellan stora och små bokstäver.

Kodningen måste också stämma. När icap_client_username_encode är aktiverat Base64-kodar Squid värdet. Tjänsten måste avkoda den representationen i stället för att behandla den som ett annat användarnamn.

Detta är metadata om ICAP-utbytet mellan Squid och dess tjänst. Det är inte en instruktion att skicka ett användaridentitetshuvud till varje målwebbplats.

Om tjänsten fortfarande rapporterar en IP-adress

Bekräfta att transaktionen faktiskt har ett autentiserat användarnamn i Squid, att vidarebefordran av användarnamnet är aktiverad och att tjänsten läser det konfigurerade huvudet. Att en adapter faller tillbaka på en klientadress bevisar inte att Squid-autentiseringen misslyckades; själva överlämningen kan saknas eller vara felaktigt namngiven.

Betrakta endast denna identitet som tillförlitlig längs den kontrollerade vägen mellan Squid och adaptern. Dessa direktiv är versionsspecifika: konfigurationsreferensen listar dem för Squid 7 och tidigare linjer och markerar dem som otillgängliga i Squid 8.

Relaterade artiklar