Cerifique-se de saber isto sobre a autenticação de declarações do SharePoint 2010 - sessões Sticky são EXIGIDAS

Artigo original publicado na sexta-feira, 28 de outubro de 2011

Olá pessoal, estou aqui para dizer que agora tenho uma história para contar, com o meu sofrimento com uma anomalia ao usar a autenticação das declarações, que eu gostaria que tivesse sido mais clara. Esse é um aspecto tão fundamental de sua implantação que eu quero garantir que seja destacado aqui, para que o mesmo não aconteça com você. 

Dito de maneira simples, se você estiver usando a autenticação de declarações DEVE usar a afinidade na sua solução de balanceamento da carga. O TechNet descreve isso, mas apenas como uma nota lateral resumida, e não de uma forma apropriadamente convincente. O artigo está em https://technet.microsoft.com/en-us/library/cc288475.aspx e diz o seguinte:

Observação: se você usa a autenticação baseada no token SAML com o AD FS em um farm do SharePoint Foundation 2010 que tem vários servidores da Web em uma configuração de carga balanceada, pode haver um efeito sobre o desempenho e a funcionalidade das exibições da página da Web do cliente. Quando o AD FS fornece o token de autenticação para o cliente, esse token é enviado ao SharePoint Foundation 2010 para cada elemento de página restrito pela permissão. Se a solução de carga balanceada não estiver usando a afinidade, cada elemento protegido é autenticado para mais de um servidor do SharePoint Foundation 2010, o que pode resultar na rejeição do token. Depois que o token é registrado, o SharePoint Foundation 2010 redireciona o cliente para autenticar novamente para o servidor do AD FS. Depois que isso ocorre, um servidor do AD FS pode rejeitar diversas solicitações feitas em um período curto. Esse comportamento é o padrão, para proteger contra um ataque de recusa de serviço. Se o desempenho for negativamente afetado ou as páginas não carregarem completamente, pense em configurar o balanceamento de carga da rede para a afinidade simples. Isso isola as solicitações do token SAML para um único servidor da Web.

Aceito a culpa por não ter percebido isso e não ter levado mais a sério, mas estou colocando no blog agora, para que não aconteça com você. Coloquei as palavras em itálico na nota, que claramente não fazem justiça (e também não deveria ser uma nota, deveria estar em letras enormes e em negrito). Se você não usar a afinidade, alguns dos seguintes problemas irão ocorrer:

• Você pode ser redirecionado aleatoriamente de volta à página de logon.
• Você pode acabar em um loop de autenticação que faz com que o AD FS interrompa a solicitação, por causa de um ataque percebido de recusa de serviço (DOS), como diz a nota.
• Se você olhar o traçado da atividade, o SharePoint configura o seu cookie fedauth para um valor vencido, e depois começa a fazer as solicitações novamente para o AD FS; isso, por motivos que eu ainda desconheço, não emite o seu cookie não expirado ou o SharePoint o analisa e o transforma em um cookie expirado. É isso que aciona o ciclo de DOS que eu descrevi acima. Em retrospecto, lembro que no passado algumas pessoas me perguntaram sobre isso, dizendo que acontecia com elas, e agora percebo que provavelmente a culpa era da falta de sessões sticky.

Em resumo, não deve haver mais confusão ou dificuldade com esse assunto no futuro – para o SharePoint 2010, se você for usar a autenticação das declarações, USE A AFINIDADE COM O SEU BALANCEADOR DA CARGA!

Este é um post de um blog localizado. Encontre o artigo original em Make Sure You Know This About SharePoint 2010 Claims Authentication - Sticky Sessions Are REQUIRED