O trabalho do BIG-IP Zero Trust Access (antigo BIG-IP APM - Access Policy Manager) depois da autenticação é continuar autenticando por você, e o capítulo de Single Sign-On Methods define exatamente oito jeitos de fazer isso: HTTP Basic, NTLMv1, NTLMv2, Kerberos com delegação restrita, Form Based, Forms - Client Initiated, OAuth Bearer e SAML. Esta ferramenta renderiza cada um como um cartão com seu mecanismo, seu encanamento de credenciais, seus pré-requisitos e suas peculiaridades, tudo condensado fielmente do capítulo e dos guias específicos de cada método.
O veredito em cada cartão é o próprio parágrafo de raio de explosão do capítulo, e ele é a manchete operacional: um objeto SSO mal configurado de HTTP Basic, NTLMv1, NTLMv2, Kerberos, OAuth Bearer ou SAML pode desabilitar o SSO de todos os métodos de autenticação naquela sessão do usuário. Form Based e Forms - Client Initiated são os únicos dois métodos que não são desabilitados quando o objeto de outro método quebra. Uma configuração Kerberos SSO ruim e toda aplicação da sessão pode perder seu SSO; uma configuração de formulário ruim e só aquela aplicação perde. Essa assimetria decide o cuidado que cada classe de objeto merece.
O cartão do Kerberos carrega a lista completa de pré-requisitos: uma conta de delegação no Active Directory por realm de servidor, seu SPN inserido como Account Name em formato SPN, o realm em maiúsculas, Resource-Based Constrained Delegation para ambientes multi-realm, e a linha do próprio manual, que vale emoldurar: o Kerberos SSO do APM não precisa nem usa um arquivo keytab. Suas portas de entrada naturais são os métodos em que a senha nunca viaja em texto claro, certificados de cliente e NTLM entre os exemplos do próprio capítulo. O NTLMv2 carrega a peculiaridade documentada de que um 401 com mais de um cabeçalho WWW-Authenticate: NTLM faz o SSO falhar, comportamento esperado segundo o manual. O Forms - Client Initiated carrega o detalhe mais engenhoso do seu desenho: o JavaScript que o APM insere atribui ao parâmetro de senha um token em vez da senha real, então a credencial nunca fica na página.
A nota de encanamento em cada consulta amarra os métodos à maquinaria: agentes da access policy populam as variáveis de sessão que o SSO consome, sendo a fiação clássica uma Logon Page seguida de SSO Credential Mapping, alimentando session.logon.last.* em session.sso.token.last.*.
Tudo roda localmente; nada do que você digita sai da página.