Uma ponte de madeira cruza águas tranquilas em direção à outra margem, na neblina da manhã.

Por dentro do Authrim

Conectar sem guardar senhas

As senhas já estão no Active Directory. Como oferecer um login moderno sem copiar hashes de senha nem publicar um novo endpoint de entrada para o conector?

Começar pelo que não pode mudar

As contas dos funcionários estão no Active Directory. As políticas de senha, os prazos de validade e a desativação de contas também. Esse sistema funciona assim há anos.

Você quer adicionar passkeys, organizar o MFA e ampliar o SSO para serviços SaaS. O objetivo é claro. A primeira pergunta continua sendo: onde a senha será verificada?

Algumas arquiteturas sincronizam hashes de senha com a nuvem; outras pedem ao diretório interno que verifique as credenciais. O importante é saber onde elas ficam, qual lado abre a conexão e quem opera esse caminho.

O WordWarden mantém a verificação no LDAP/AD e permite escolher o caminho. O Authrim Relay oferece uma conexão de saída para organizações que não querem publicar um novo endpoint de entrada.

O que o WordWarden faz

O Authrim WordWarden é um conector de diretório: um pequeno serviço instalado perto do LDAP/AD. Sua tarefa é bem definida: receber usuário e senha, consultar o diretório e devolver o resultado.

Interface de login, sessões, passkeys, códigos por e-mail, federação, correlação de auditoria e mapeamento de identidades ficam com o Authrim. O WordWarden faz apenas a verificação junto ao diretório.

A direção da conexão muda a configuração da rede e os componentes que você precisa operar.

Quem se conecta a quem?

O WordWarden oferece três formas de conexão. A diferença é se sua rede precisa publicar um ponto que aceite conexões externas.

SUA REDE AUTHRIM (NUVEM) LIMITE Direct HTTPS WordWarden endpoint público necessário Authrim O Authrim se conecta ao endpoint publicado Cloudflare Tunnel WordWarden + cloudflared host não exposto diretamente Authrim O cloudflared abre uma conexão pelo Cloudflare Tunnel Authrim Relay WordWarden apenas conexão de saída Authrim Relay (Durable Object) O WordWarden inicia a conexão, sem endpoint de entrada
As setas mostram qual lado abre a conexão. No Direct HTTPS, o Authrim se conecta a um endpoint publicado. Tunnel e Relay iniciam conexões de saída da sua rede: o Tunnel usa o processo separado cloudflared, enquanto o próprio WordWarden mantém a conexão com o Relay.

Qual opção combina com seu ambiente?

Se a nova implantação não deve acrescentar acesso de entrada, comece avaliando o Relay. Uma estrutura de publicação ou um túnel já existente também pode ser útil. Os exemplos abaixo são cenários de implantação, não relatos de clientes.

Authrim Relay: manter o AD interno, sem novo acesso de entrada

Pense em uma empresa com AD na sede que exige uma avaliação para cada novo servidor público, ou em uma universidade que não permite conexões de entrada na rede LDAP do campus. O WordWarden abre a conexão com o Authrim, sem precisar publicar uma nova porta de entrada nessa rede.

Não é necessário um novo endpoint público nem um processo separado de túnel. O tráfego WebSocket de saída precisa ser permitido, e o funcionamento do WordWarden e o estado da conexão ainda precisam ser monitorados. O Relay não atende uma rede que proíbe toda comunicação externa.

Cloudflare Tunnel: aproveitar um túnel já em uso

Uma organização que já publica ferramentas internas pelo Cloudflare Tunnel pode ter uma equipe responsável por atualizar o cloudflared e manter as rotas. O WordWarden pode aproveitar esses processos sem abrir uma nova porta de entrada.

Você configura o hostname e a rota pelos quais o Authrim alcança o conector e mantém o túnel. O host interno não precisa aceitar conexões diretas de entrada, mas as requisições chegam por uma rota no Cloudflare.

Direct HTTPS: usar uma plataforma de API já existente

Uma empresa, universidade ou instituição de pesquisa pode já ter uma equipe que opera uma DMZ e um proxy reverso para integrações externas. Um endpoint HTTPS acessível ao Authrim pode seguir os processos existentes de certificados, logs de acesso e monitoramento.

Não é preciso manter uma conexão separada de túnel ou Relay. Em troca, a organização permite a rota de entrada e assume a proteção e a manutenção do endpoint público. O que se publica é a interface HTTPS do conector, não a porta LDAP/AD diretamente na internet.

Em todas as opções, o WordWarden precisa ser operado em um local com acesso ao LDAP/AD. Ser uma instituição acadêmica não determina a escolha; a infraestrutura e a política de rede, sim.

Authrim Relay: a conexão começa dentro da rede

No modo Relay, o WordWarden se conecta ao Authrim por WebSocket a partir da sua rede. O WebSocket mantém uma conexão aberta pela qual os dois lados podem enviar mensagens.

O WordWarden mantém essa conexão aberta e aguarda. Quando alguém faz login, o Authrim usa o mesmo canal para pedir a verificação. O WordWarden consulta o diretório interno e devolve o resultado.

É como fazer uma ligação de dentro da organização e permanecer na linha: a outra pessoa também pode falar. Não é preciso abrir uma nova conexão de entrada a cada pedido.

Na prática, o lado do diretório não precisa publicar uma URL. Isso evita administrar hostname, certificado e WAF para um novo endpoint público. Ainda são necessários permissão de saída, manutenção do WordWarden e monitoramento da conexão.

Detalhe técnico: WebSocket e portas de entrada

A diferença é qual lado inicia a conexão. No Direct HTTPS, a organização oferece um endpoint ao qual o Authrim pode se conectar. No Relay, o WordWarden interno abre uma conexão WebSocket criptografada (wss) com o Relay do Authrim.

Um firewall com controle de estado ou um dispositivo NAT normalmente acompanha as conexões iniciadas de dentro e permite o tráfego de retorno. Assim, o WordWarden recebe pedidos de verificação sem publicar uma porta de entrada nem configurar redirecionamento de portas para novas conexões externas.

Isso não significa que nenhuma porta é usada. Uma conexão wss típica usa a porta TCP 443 no destino. O firewall ou proxy deve permitir a saída para o Relay e conexões WebSocket persistentes. Enquanto o canal estiver desconectado, as requisições não chegam por ele. Por isso, monitorar a conexão continua sendo necessário.

Reduzir os endpoints para novas conexões externas não elimina os pedidos recebidos pelo canal já aberto. Autenticar a outra ponta e validar as requisições continuam sendo necessários.

Referência: The WebSocket Protocol (RFC 6455)

Uma conexão de saída também precisa de autenticação. O Relay combina a autenticação do conector com verificações do destino configurado.

Detalhe técnico: autenticação com HMAC

O WordWarden responde a um desafio de curta duração com um HMAC, assinando uma sequência de caracteres que contém o ID do desafio e o nonce. Ele também verifica se os IDs do tenant e do conector na URL de destino correspondem à sua configuração.

O HMAC é obrigatório nas três formas de conexão. O Relay reduz a exposição de entrada, mas não elimina a autenticação do conector nem a gestão de segredos.

O que realmente atravessa o limite

Aqui é importante ser preciso. Seria incorreto dizer que a senha nunca sai da sua rede.

A pessoa digita a senha na tela de login, e ela passa pelo Authrim. A afirmação correta é: “O Authrim e o WordWarden não armazenam a senha.”

SUA REDE AUTHRIM (NUVEM) Senha segue ao diretório, sem ser armazenada LDAP / AD verifica a senha WordWarden Authrim Usuário Resultado e atributos permitidos voltam ao Authrim ARMAZENADO no diretório NÃO ARMAZENADO (WordWarden / Authrim) senha ou hash de senha incluindo hashes de sistemas legados O Authrim guarda sessões, perfis e dados de passkeys
A documentação é explícita: o Authrim não deve importar, gerar hashes, recalcular hashes nem persistir senhas. Isso inclui hashes de senha vindos de sistemas legados.

A resposta também é limitada

Quando a verificação tem sucesso, o Authrim recebe o resultado e os atributos solicitados, limitados pela lista local de permissões do conector. Quem pede não decide sozinho o que pode obter: o lado do diretório define o que será liberado.

Essa direção importa: uma alteração apenas no Authrim não pode ampliar o conjunto de dados que sai da sua rede.

A senha como etapa de transição

Essa integração existe, acima de tudo, para permitir uma transição.

O LDAP/AD continua responsável pelas senhas. As pessoas seguem entrando com a conta que já têm. As passkeys são cadastradas aos poucos. O código por e-mail permanece como caminho de recuperação. O acesso continua funcionando enquanto a forma de autenticar muda.

A documentação também é clara neste ponto: não exporte hashes de senha do LDAP/AD para o Authrim. Isso transformaria a conexão de transição em uma cópia das credenciais.

Em preparação para a beta pública. A primeira versão prevista é v0.1.0-beta.1.

Voltado a projetos-piloto: organizações capazes de operar um pequeno serviço perto do LDAP/AD e compreender os limites de responsabilidade do diretório, da rede, do TLS e da gestão de segredos. Não é um serviço de diretório gerenciado.

Exige Authrim 0.3.2 ou posterior, com Directory Authentication e Relay ativados. Na beta atual, mudanças de configuração exigem reiniciar o processo.

“Copiar credenciais para fora ou abrir acesso para dentro”
não são as únicas opções.

Verifique junto ao diretório e inicie a conexão de dentro. Assim, é possível oferecer um login moderno sem copiar hashes de senha nem publicar um ponto de entrada na rede interna.

O destino é a adoção de passkeys. A integração com o diretório dá a base para essa migração acontecer sem impedir ninguém de entrar.