Apache Httpd - autorização de ponto final com balanceamento de carga

Question

O Apache Httpd está sendo usado como um balanceador de carga entre dois servidores de ponto final. Cada servidor tem sua própria autenticação HTTP. O objetivo é que a autenticação do ponto final seja passada ao usuário, o usuário insira suas credenciais e a autenticação seja passada de volta ao servidor do ponto final.

Quando eu configuro o Apache como um proxy reverso, a autenticação é passada sem nenhum problema. Quando eu vou ao localhost, eu sou solicitado por credenciais, eu as insiro e, em seguida, o site funciona bem. Aqui está minha configuração para o proxy reverso:

<VirtualHost *:80>
    ProxyPass "/" "http://serv123:27001/"
    ProxyPassReverse "/" "http://serv123:27001/"
    <Location "/">  
        SetEnv proxy-chain-auth On 
    </Location> 
</VirtualHost>

Mas, quando adiciono balanceamento de carga, parece que a autenticação de cadeia de proxy não está configurada corretamente. Quando eu insiro as credenciais, imediatamente me avisam novamente como se não tivessem sido digitadas corretamente.

<VirtualHost *:80>
    ProxyPass "/" "balancer://mycluster/"
    ProxyPassReverse "/" "balancer://mycluster/"

    <Location "/">  
        SetEnv proxy-chain-auth On 
    </Location>

    <Proxy "balancer://mycluster">
        BalancerMember "http://serv123:27001/"
        BalancerMember "http://serv456:27001/"
    </Proxy>
</VirtualHost>

Eu também tentei <Location "balancer://mycluster"> e <Location "balancer://mycluster/"> sem sucesso. Alguém sabe a maneira correta de passar a autenticação através do Apache Httpd com balanceamento de carga?

    

Answer 1

Nesta construção de balanceamento, cada solicitação pode (e provavelmente será) respondida pelo outro servidor, portanto o cookie do navegador contendo o sessionid é sobrescrito em cada solicitação-sequência de login e a sessão parece ser sempre inválida.

Existem várias formas de contornar este problema:

• Se usar stickysessions for uma opção, você poderá usar esse sistema simples para garantir que os usuários sempre sejam manipulados pelo mesmo servidor (contanto que ele esteja ativo e o cookie seja válido). A desvantagem é: quando o servidor morre, o usuário precisa fazer o login novamente. link

• Se perder uma sessão estiver totalmente fora de questão, verifique se os aplicativos nos dois servidores sempre conhecem todos os logins / sessões. Assim, você poderia usar um back-end de banco de dados (ou até mesmo salvar essas informações em um armazenamento central como arquivos) para salvá-las e validar cada solicitação em relação a essas sessões armazenadas em db. A desvantagem é a troca de servidor em todas as outras solicitações, o que mata a eficiência do armazenamento em cache no lado do servidor.

• combine as duas tentativas para permitir o armazenamento em cache eficiente: as solicitações subsequentes sempre são tratadas pelo mesmo servidor (sessões persistentes) e quando um servidor falha, o outro assume e reconstrói a sessão a partir do backend da sessão. O armazenamento em cache deve ser refeito neste momento, desde que você não use uma abordagem compartilhada do memcached ou semelhante.