Por Jennifer Vesperman - 09/08/2001
A autenticação HTTP usa os mesmos protocolos básicos para servidores web HTTP e servidores proxy HTTP. Estes protocolos possuem dois modos de autenticação: básico e digest. No modo básico, o cliente passa um nome de usuário e a senha para o servidor em um único bloco codificado em base64. No modo digest, o servidor codifica a senha com uma chave diferente em uma função unidirecional e o cliente decodifica a função usando a senha, e retorna a chave. Isto prova que o cliente conhece a senha, sem na verdade transmitir a senha em nenhum momento.
Para o servidor (web ou proxy), a autenticação HTTP é 'stateless'. Para a maioria dos clientes, não é -- em uma dada sessão, a maioria dos clientes retém os pares nome de usuário/senha para nomes de hosts e caminhos (ou mais precisamente, para realms HTTP) que tenham requerido autenticação previamente.
Se o cliente já tem um par de nome de usuário/senha para uma URL, ele então envia a solicitação de página. Se o cliente não enviar os dados de autenticação junto com a solicitação para uma página que exige autenticação, o servidor envia automaticamente um desafio antes de enviar a página. O cliente recebe o desafio e pede ao usuário pelo par nome de usuário/senha a ser enviado.
O método usual para evitar que outro usuário com o mesmo cliente use o nome de usuário e senha é fechar o cliente. Isto encerra a sessão, e a maior parte dos clientes descarta quaisquer pares nome de usuário/senha existentes.
alguns browsers são persistentes e existem enquanto o desktop estiver ativo. Algumas versões destes irão descartar os pares nome de usuário/senha quando o browser HTTP for fechado, mas outros parece que não.
Como o protocolo é 'stateless' para o servidor, o servidor não pode (dentro do protocolo) bloquear a autenticação de múltiplos clientes utilizando o mesmo nome de usuário, ou encerrar a sessão de um usuário. Correções ao software servidor podem ser escritos para forçar comportamentos do tipo logout em um cliente, ou para bloquear múltiplos clientes baseados no endereço IP, mas estse não são suportados pelo protocolo e podem ser não efetivos ou arriscados.
O Squid possui uma opção (authenticate_ip_ttk) para "colar" a
autenticação ao endereço IP por um período de tempo. O padrão é 0 segundos,
que não faz a aderência e, portanto, é correto de acordo com o protocolo.
A autenticação de servidor proxy usa os mesmos protocolos e técnicas da
autenticação de servidor web, mas envia um desafio com o campo
proxy-authenticate, em vez do campo
www-authenticate. O modo digest é escrito no protocolo, mas a
autenticação proxy é atualmente não suportada em muitos brosers e a maioria
dos proxy e servidores cache HTTP.
Em uma cadeia de proxies, a autenticação de proxy é consumida pelo proxy mais perto do cliente que solicita autenticação, e a informação de autenticação não é passada para os proxies pai. Note que os proxies que não exigem autenticação não necessariamente passam a autenticação de proxy adiante.
A autenticação de usuários do Squid é configurada em
$SQUID-HOME/etc/squid.conf. As seções que devem ser configuradas
são:
É necessário compilar e instalar o seu módulo de autenticação.
O realm é configurado com a linha proxy_auth_realm.
O usuário verá o realm na janela de diálogo de solicitação de nome de
usuário/senha. O valor padrão é Squid proxy-caching web server,
mas você pode querer alterar conforme a autenticação é feita contra o
realm.
# realm example
proxy_auth_realm Squid proxy-caching web server
Para informar ao Squid que este deve solicitar autenticação de usuário, é necessário acrescentar duas linhas de controle de acesso especiais. As linhas são:
acl name proxy_auth REQUIRED
http_access allow name
Estas linhas são inversas em relação à lógica ACL normal. Normalmente, estas linhas permitiriam acesso a todas as pessoas que passaram pela autenticação do proxy -- entretanto, elas na verdade negam o acesso a todo mundo que tenha falhado na autenticação. Por esta razão, o seguinte formato é recomendado para listas de controle de acesso que exigem autenticação de usuários:
# set up the acl name for the local network
acl localnetwork proxy_auth foo.bar.baz/xy.zz.y
#set up the acl name for user authentication
acl localusers proxy_auth REQUIRED
# set up all the denies for those not in the local network
http_access deny !localnetwork
# set up the user authentication
http_access allow localusers
# set up the allows for the local network
http_access allow localnetwork
# deny anything that passes beyond this point
http_access deny all
Isto garante que qualquer um que seja recusado por estar fora da rede local é recusado diretamente, sem passar pelo processo de autenticação de usuário. é muito confuso para um usuário ser solicitado por um nome de usuário e senha e ser recusado mesmo após entrar com um par válido.
Aqueles que falham a autenticação de usuário são negados na ergra
http_access allow localusers, mas aqueles que passarem pela
autenticação são passados para a próxima linha. Esta é a regra explícita que
permite acesso para a rede local. Se ela não estivesse aqui, os usuários
cairiam na regra http_access deny all e teriam o acesso
negado.
As ACLs do Squid possuem uma regra final implícita que reverte a regra
precedente. Se a última regra era http_access allow localusers, a
regra implícita final será http_access deny all. Usuários
autenticados serão passados para a regra deny all, e terão o
acesso negado. Este é um erro de configuração comum.
O formato a seguir irá falhar por que qualquer usuário na rede local terá acesso permitido ao proxy e a autenticação não será verificada:
# set up the allows for the local network
http_access allow localnetwork
# set up the user authentication
http_access allow localusers
O formato a seguir irá falhar por que se a autenticação de usuário tiver
sucesso, então a checagem irá passar para deny all. Regras de
autenticação de usuários do tipo allow <whatever> funcionam
como se fossem deny !<whatever>:
# set up the user authentication
http_access allow localusers
# deny anything that passes beyond this point
http_access deny all
O módulo de autenticação é configurado com a opção
authenticate_program authentication module authentication
file:
# authenticate_program example
authenticate_program /squid/bin/ncsa_auth /squid/etc/passwd
Os módulos de autenticação padrão estão em
$SQUID-HOME/$SQUID-VERSION/auth_modules/. Para compilar e
instalar os módulos, vá aos seus subdiretórioes e execute make,
seguido de make install.
Exemplo:
auth_modules% cd NCSA
NCSA% make
NCSA% make install
Executa autenticação contra bancos de dados LDAP. Este módulo necessita das bibliotecas open LDAP de Openldap.org. Veja o arquivo README no diretório do módulo LDAP.
Autenticação contra um domínio Microsoft NT. Este módulo necessita que sejam feitas alterações ao código fonte. Veja o arquivo REAME no diretório do módulo MSNT.
Autenticação contra o mesmo tipo de arquivo password de muitos servidores web tipo NCSA. Não há documentação visível, mas o código é legível.
Módulo de Autenticação Plugável. Ideal para sistemas
PAM-enabled como o Debian Linux. O PAM é configurável para usar uma variedade
de sistemas de autenticação. As instruções estão nos comentários no arquivo
.c.
Autenticação contra um servidor SMB tipo Windows NT ou Samba.
Veja o arquivo README no diretório do módulo SMB
Autenticação feita contra os arquivos Unix passwd ou shadow, ou
arquivos similares podem ser lidos pela função de biblioteca C
getpwnam(). Não há documentação visível ou código legível. man
getpwnam discute a função. Para usar o arquivo de senhas shadow, o
autenticador terá que ser setuid root.
Os módulos de autenticação doados por terceiros estão disponíveis em http://www.squid-cache.org/related-software.html. Quando este estava sendo escrito, havia um autenticador RADIUS, uma modificação ao autenticador LDAP para servidores não anônimos, e um patch que suporta pesquisas LDAP dinâmicas e estáticas de grupos.
O Squid utiliza sub-processos para processar solicitações de autenticação
para evitar ser bloqueado por conexões lentas. Os sub-processos de
autenticação são conectados ao Squid por pipes Unix padrão e o Squid
comunica-se com eles através de stdin e stdout. O
sub-processo responde com "OK" ou "ERR", dependendo do sucesso da
autenticação.
Como cada solicitação tem que ser autenticada, o Squid coloca em cache os pares nome/senha junto com os resultados de autenticações corretas por um número de segundos configurável. Isto permite que o Squid envie solicitações para cada item de uma página, e ainda assim somente uma autenticação do cliente do usuário.
Devido ao cache, é impraticável para muitos usuários compartilharem um nome
de login. O Squid utiliza árvores splay para manipular o cache
interno, e estas não respondem bem à chaves duplicadas.
http_access allow localusers funciona como se estivesse escrita
http_access deny !localusers.
Agora o seu chefe saiu do seu pé e sua autenticação de proxy está funcionando -- vá pegar uma bebida e levante seus pés. A menos que ele esteja atrás de você para outro trabalho...
$SQUID-HOME/etc/squid.conf/
Versão inglesa oreillynet.com Copyright © 2000 O'Reilly & Associates, Inc.
Tradução do original em http://www.oreillynet.com/pub/a/linux/2001/08/09/authen_squid.html