O single sign-on no BIG-IP Zero Trust Access (o antigo BIG-IP APM, Access Policy Manager) não é um recurso só: são oito, e o capítulo Single Sign-On Methods dá nome a cada um: HTTP Basic, NTLMv1, NTLMv2, , Form Based, Forms - Client Initiated, Bearer e . Cada um leva a identidade já autenticada do usuário até um backend do seu próprio jeito, repassando a credencial ou trocando-a por outra, e cada um é configurado como um objeto que o access profile entrega aos recursos. O explicador de métodos SSO mostra os oito como cartões; este artigo percorre as propriedades que pesam nas decisões de projeto.

O raio de impacto (blast radius) que o capítulo anuncia logo no início

O parágrafo de abertura do capítulo traz a frase que deveria orientar toda revisão de configuração: configurar errado um objeto SSO de HTTP Basic, NTLMv1, NTLMv2, Kerberos, OAuth Bearer ou SAML pode desabilitar o SSO de todos os métodos de autenticação da sessão do usuário quando ele acessa um recurso que usa o objeto mal configurado. Form Based e Forms - Client Initiated são as exceções: os únicos métodos de SSO que não são desabilitados quando outro método falha por causa de um objeto com defeito. Leia isso como uma assimetria de consequências: um erro de digitação na configuração de um formulário custa o SSO daquela aplicação; um erro de digitação num objeto Kerberos ou (NT Manager) pode custar tudo à sessão. Os objetos que não são de formulário merecem um controle de mudanças à altura desse raio de impacto.

O que cada método transporta de fato

O HTTP Basic é o mais direto: o plug-in de SSO envia cada requisição com um header (cabeçalho) Authorization que leva o de usuário, dois-pontos e senha. Base64 é codificação, não proteção; por isso, o caminho até o backend faz parte do projeto de segurança, e não é um detalhe para depois. Os dois métodos NTLM usam o challenge-response (desafio e resposta) do protocolo, de modo que a senha em si nunca chega ao servidor, e o v2 é a versão atualizada. O v2 também tem uma peculiaridade documentada que vale decorar: uma resposta 401 com mais de um header WWW-Authenticate: NTLM faz o SSO NTLMv2 falhar, e o manual diz que esse comportamento é esperado.

O Kerberos é a opção transparente para servidores web Windows ingressados no domínio do , e os pré-requisitos dele são tão específicos que o cartão do explicador parece um checklist: uma conta de delegação por realm de servidor, dedicada e configurada para não expirar; o (Service Principal Name) dessa conta informado como Account Name, no formato SPN; o realm em maiúsculas; e, para servidores espalhados por vários realms, uma conta de delegação no realm principal, com Resource-Based Constrained Delegation concedida nos realms confiáveis. O manual acrescenta uma linha que resolve de uma vez uma confusão antiga: o Kerberos SSO do APM não precisa de arquivo keytab e não usa um. O Kerberos SSO combina naturalmente com métodos de autenticação em que a senha nunca trafega em claro na entrada; os exemplos do próprio capítulo são certificados de cliente e NTLM. É exatamente o padrão dos projetos modernos com SAML na frente: federação na entrada, delegação no backend.

Os dois métodos de formulário automatizam o formulário de login da própria aplicação. O Form Based monta o formulário e faz o POST do lado do servidor: a Start URI decide quando ele entra em ação, um Form Action em branco faz com que seja usada a URL original da requisição, e a origem da senha, por padrão, é a variável session.sso.token.last.password. O Forms - Client Initiated é o irmão mais sutil: o APM detecta a página de logon por uma URI, um header ou um cookie configurado, deixa a própria aplicação servir o formulário e então insere um JavaScript gerado que preenche e envia o formulário automaticamente. O guia de configuração registra o melhor detalhe desse desenho: o parâmetro de senha recebe um token de senha, e não a senha real do usuário, e o servidor resgata esse token quando o formulário é enviado. A credencial nunca fica no código-fonte da página. OAuth Bearer e SAML completam os oito transportando tokens e asserções emitidos, em vez de senhas em cache, e os dois estão no grupo dos métodos que, com um objeto errado, contaminam a sessão inteira.

O que existe por baixo dos oito métodos

Todo método consome o que a access policy guardou em cache. A ligação clássica é uma Logon Page (ou uma forma de entrada sem senha) preenchendo a session.logon.last.username e as variáveis irmãs dela, seguida de um agente SSO Credential Mapping que alimenta as variáveis session.sso.token.last.* lidas pelos objetos SSO; a configuração NTLM Domain, por exemplo, usa por padrão diretamente a session.logon.last.domain. Quando o SSO se comporta mal, o primeiro passo honesto é abrir a própria visualização de variáveis de sessão do APM para a sessão ativa: se as variáveis que o método lê estão vazias ou erradas, nenhuma configuração de objeto SSO vai resolver. Essa camada de variáveis merece uma referência própria: a referência de variáveis de sessão traz a tabela do manual, resolve os nomes escritos como padrões (templates) e aponta a armadilha da flag -secure em expressões coladas.