WebAuth (web authentication)

Significa: Web-based network authentication: the browser login a switch or controller forces before a port or wireless session is opened

Autenticação web: o recurso do switch ou da controladora que intercepta a primeira requisição de navegador de um cliente novo, serve uma página de login, confere as credenciais num servidor RADIUS e só então abre a porta ou a sessão, para pessoas em dispositivos que não conseguem fazer 802.1X.

O guia de segurança do Catalyst 9300 da Cisco descreve o recurso, conhecido como web authentication proxy, como o jeito de autenticar usuários finais em sistemas que não rodam o suplicante IEEE 802.1x. A sequência é a que todo hóspede de hotel conhece: o usuário inicia uma sessão HTTP, o tráfego HTTP é interceptado e a autorização é iniciada, o switch envia a página de login ao usuário, as credenciais vão ao servidor de autenticação e, se a autenticação tem sucesso, o switch baixa e ativa a política de acesso do usuário a partir do servidor; na falha o switch serve uma página de erro e, esgotado o número máximo de tentativas, envia a página de login expirado e coloca o host numa lista de observação. O guia descreve o switch como um intermediário (proxy) entre o cliente e o servidor de autenticação, detecta hosts por ARP e por DHCP snooping e declara um limite que explica muita dor de cabeça moderna: a interceptação de tráfego HTTPS para redirecionamento de autenticação web central não é suportada. A resposta do IETF à interceptação, a arquitetura de portal cativo da RFC 8952 com as opções de DHCP e de anúncio de roteador da RFC 8910, é o lado dos padrões; o verbete portal cativo tem a visão do usuário. Na ordem de contingência de uma porta, a autenticação web vem depois do 802.1X e do MAB.

A autenticação web é o terceiro caminho para dentro de uma porta autenticada, depois do 802.1X para dispositivos com suplicante e do MAC Authentication Bypass para coisas numa lista, e é o que foi feito para pessoas: um visitante com um notebook sem suplicante configurado, um terceirizado num dispositivo pessoal, um estudante numa rede de campus. O guia de configuração de segurança do Catalyst 9300 da Cisco, em seu capítulo sobre configurar a autenticação baseada em web, manda usar o recurso, conhecido como web authentication proxy, para autenticar usuários finais em sistemas que não rodam o suplicante IEEE 802.1x. O projeto é um intermediário executado pela rede de propósito: o switch se põe entre o navegador e o servidor de autenticação e, nas palavras do guia em Device Roles, age como intermediário (proxy) entre o cliente e o servidor de autenticação, pedindo informações de identidade ao cliente, verificando-as com o servidor de autenticação e repassando uma resposta ao cliente.

A sequência na seção Authentication Process do guia é a que um usuário vive como uma página de login surgindo do nada. O usuário inicia uma sessão HTTP; o tráfego HTTP é interceptado e a autorização é iniciada, e o switch envia a página de login ao usuário; o usuário digita credenciais, que o switch envia ao servidor de autenticação por RADIUS; se a autenticação tem sucesso, o switch baixa e ativa a política de acesso do usuário a partir do servidor e mostra uma página de sucesso. Na falha o switch envia a página de falha de login, o usuário tenta de novo e, se o número máximo de tentativas falha, o switch envia a página de login expirado e o host é colocado numa lista de observação. As quatro páginas, Login, Success, Fail e Expire, são personalizáveis, e um Local Web Authentication Banner pode carregar o texto ou o logotipo de uma organização na página de login e nas janelas de resultado. Antes de qualquer coisa disso acontecer o switch precisa notar o host, e o guia lista os gatilhos para uma porta de camada 2: um gatilho baseado em ARP que pega hosts com endereço estático ou dinâmico, a inspeção dinâmica de ARP e o DHCP snooping, que avisa a autenticação web quando um vínculo é criado. A sessão é reautenticada quando um host numa interface de camada 2 para de responder a sondas ARP, ou quando um host numa interface de camada 3 não envia nada dentro do tempo ocioso.

A dependência do mecanismo em relação à interceptação é também o seu declínio, e o guia declara o limite sem suavizar: a interceptação de tráfego HTTPS para redirecionamento de autenticação web central não é suportada. Um navegador cuja primeira requisição é HTTPS, que hoje é a primeira requisição da maioria dos navegadores, não pode ser redirecionado sem um aviso de certificado, e o mesmo vale para aplicativos com certificados fixados e para o DNS cifrado. A resposta do IETF foi parar de fingir. A RFC 8952, Captive Portal Architecture, de novembro de 2020, descreve uma arquitetura de equipamento de usuário, serviço de provisionamento, servidor da API do portal cativo, dispositivo de imposição e sinal de portal cativo, em que a rede avisa ao dispositivo, em vez de enganá-lo, que um portal existe; ela afirma que as soluções não devem exigir a falsificação de respostas de servidores DNS ou HTTP. A RFC 8910, de setembro de 2020, dá à rede os meios: a opção 114 do DHCPv4, a opção 103 do DHCPv6 e a opção 37 do anúncio de roteador carregam a URI da API do portal cativo, substituindo uma opção 160 depreciada que se comportara mal em campo. Sistemas operacionais que implementam isso ficam sabendo do portal na atribuição de endereço e o abrem por conta própria. O verbete portal cativo descreve a visão do lado do usuário da mesma história.

Nas implantações corporativas os nomes importam. A autenticação web local é o recurso descrito acima, com o switch ou a controladora servindo as páginas; a autenticação web central move o portal para o motor de política, com o switch redirecionando para ele e o motor devolvendo a autorização, em geral com um Change of Authorization do RADIUS depois que o usuário entrou, que é a configuração a que o limite de HTTPS acima se refere. De um jeito ou de outro, a identidade estabelecida é a de uma pessoa, conferida nos mesmos servidores RADIUS e diretórios que tudo o mais, e a autorização que se segue deveria ser a de um visitante, uma VLAN ou um filtro que alcança a Internet e nada interno.

A ordem de contingência numa porta é o resumo do projeto: 802.1X primeiro, porque autentica o dispositivo com uma credencial; MAB em seguida, para as coisas numa lista; autenticação web por último, para as pessoas em dispositivos que não fazem nem um nem outro. Os verbetes 802.1X e MAB cobrem os dois primeiros, e o artigo sobre autenticação web e portais cativos põe o recurso corporativo ao lado dos padrões que estão substituindo a interceptação.

Também conhecido como: web authentication, web-based authentication, web authentication proxy, central web authentication, local web authentication, guest portal

Fontes

← Todos os verbetes do glossário