Backends legados nunca foram projetados para aceitar identidade moderna
Muitas aplicações em execução dentro de uma empresa — portais internos, sistemas de faturamento, consoles de operações, painéis de administração fornecidos por terceiros, ferramentas legadas de linha de negócio — foram criadas antes de SAML ou OIDC se tornarem predominantes. Elas normalmente reconhecem o usuário não por tokens modernos, mas por um header HTTP, uma credencial Basic-Auth ou um cookie de sessão que já confiam.
Migrar essas aplicações para SSO moderno parece simples na teoria: reescrever o caminho de autenticação do backend, adicionar suporte a SAML/OIDC e conectar a aplicação ao provedor de identidade central. Na prática, quase nunca acontece. O código-fonte pode ser antigo, a aplicação pode ser de propriedade do fornecedor, a mudança pode quebrar um fluxo de trabalho regulamentado, ou o custo simplesmente não se justifica para uma ferramenta interna que funciona.
As organizações ficam então presas entre duas opções ruins: deixar as aplicações legadas fora do perímetro de identidade moderno, ou construir uma integração frágil e separada para cada uma. O resultado final é uma experiência do usuário fragmentada, controle de acesso descentralizado e lógica de identidade espalhada pelo modelo legado de cada backend.
A abordagem correta é posicionar a camada de acesso moderna na frente da aplicação. O usuário passa primeiro pela identidade central, MFA, acesso condicional e verificações de confiança de dispositivo; a identidade autenticada é então traduzida para um formato que o backend já entende. A aplicação recebe uma experiência SSO moderna sem qualquer alteração de código.
Mas essa transição precisa ser feita com cuidado. Se headers de identidade falsos do usuário forem encaminhados ao backend sem serem removidos, qualquer pessoa pode adicionar seu próprio header X-Auth-User à requisição e se passar por outro usuário. O gateway deve remover valores de entrada não confiáveis, injetar apenas a identidade confiável que ele mesmo produz, e delimitar isso estritamente por rota.
Logout, perda de sessão e estado de identidade iniciado pelo backend também precisam fluir pelo mesmo motor. Caso contrário, o usuário pode parecer desconectado no portal enquanto a sessão do backend continua ativa, ou a sessão do backend pode ser encerrada sem que a camada de acesso perceba.
O Backend SSO não se trata de forçar a reescrita de aplicações legadas — trata-se de colocar o controle de identidade moderno na frente da aplicação e traduzir com segurança a identidade do usuário autenticado para a linguagem que o backend já aceita.
Como abordamos
Um objeto de configuração por backend, cinco formatos de injeção, coordenados com o restante do motor de acesso.
Remove todo valor recebido, depois injeta o autenticado
Toda regra de injeção primeiro remove qualquer cópia de entrada do header, cookie ou valor de Authorization de destino, depois injeta a versão derivada da sessão autenticada. Um usuário que envia seu próprio "X-Auth-User" não pode se passar por outra pessoa — seu header é removido antes que o gateway adicione o confiável.
Cinco formatos de injeção para os padrões legados que encontramos
Headers personalizados (X-Auth-User, X-Forwarded-User, qualquer coisa que o backend espera), Authorization Basic para aplicações que querem um par usuário:senha, Authorization Bearer para backends amigáveis a tokens, mesclagem de valor de Cookie para aplicações que leem um cookie nomeado, e SAML-SP para backends que esperam uma asserção SAML assinada. Cada injeção tem sua própria configuração; um backend pode usar vários formatos ao mesmo tempo.
Condições por injeção delimitam cada regra às rotas corretas
Cada regra de injeção carrega sua própria expressão de condição — aplicar apenas no caminho de administrador, apenas quando um atributo de sessão específico estiver presente, apenas para um tenant. O mesmo backend pode receber identidade mais rica em rotas privilegiadas e um subconjunto mínimo em rotas públicas.
Sessão perdida do backend e logout iniciado pelo backend retornam pelo gateway
Quando o backend informa que a sessão do usuário acabou (um formato de resposta conhecido por serviço), ou quando o próprio backend desconecta o usuário, o AAM detecta o sinal, limpa a sessão do lado do gateway e redireciona conforme a política configurada. A precedência logout-wins garante que a limpeza sempre seja executada antes de qualquer injeção adicional.
Capacidades
Cinco formas de injeção, a disciplina de remoção de entradas que as torna seguras, mais as formas próprias de um parque Windows — início de sessão Kerberos à frente, NTLM publicado de forma transparente atrás.
Injeção de header — qualquer nome de header em que o backend confia
O formato mais simples e mais comum. Configure um nome de header (X-Auth-User, X-Forwarded-User, REMOTE_USER, qualquer coisa que o backend leia) e a variável inteligente que produz o valor (nome de usuário, email, lista de grupos, nome de exibição). O header é removido das requisições de entrada, depois re-adicionado a partir da sessão autenticada antes que a requisição alcance o backend.
Injeção de Authorization Basic para aplicações que querem usuário:senha
Para aplicações legadas que se autenticam via HTTP Basic, o gateway injeta Authorization: Basic
Injeção de Authorization Bearer para backends cientes de tokens
Para backends que já falam Bearer tokens (APIs internas, microsserviços, aplicações de intranet modernas) o AAM injeta Authorization: Bearer
Injeção de valor de Cookie com mesclagem segura de header único
Aplicações que leem identidade de um cookie nomeado são acomodadas com injeção de valor de cookie. O gateway mescla o par name=value injetado no header Cookie da requisição sem sobrescrever os outros cookies — o mais propenso a erros dos quatro formatos de estilo de header, tratado com lógica de mesclagem explícita em vez de sobrescritas ingênuas.
Injeção SAML-SP — uma asserção SAML assinada por requisição
Para backends que esperam uma asserção SAML assinada em cada requisição, o gateway cria uma asserção SAML 2.0 a partir da sessão autenticada, assina-a com a chave de assinatura SAML do AAM e a encaminha no header configurado ao backend. Típico para integrações de federação de identidade do setor público e backends SaaS corporativos. O usuário faz login com um IdP moderno; o backend recebe uma asserção SAML atualizada e com escopo em cada requisição.
Disciplina de remoção de entrada aplicada a todo valor injetado
Toda injeção é emparelhada com uma remoção de entrada do mesmo alvo. Um usuário que define X-Auth-User em sua própria requisição, que envia um Cookie falsificado com um valor de identidade adulterado, ou que reproduz um header de Authorization de algum outro lugar não pode fazer o valor sobreviver além do gateway. A injeção só é executada após a remoção ter limpo o slot.
Condições por injeção para escopo e precedência
Cada regra de injeção pode anexar uma condição — mesma linguagem de expressão que a política de acesso condicional. Injetar apenas no caminho de administrador; injetar apenas quando o usuário estiver em um grupo específico; injetar a variante privilegiada apenas quando um atributo estiver presente. As condições são compiladas de forma segura quanto à precedência ACL para que múltiplas regras em um backend sejam compostas corretamente.
Proteção autenticado-apenas em torno de toda injeção
Todas as injeções estão protegidas pelo estado autenticado — elas são executadas apenas quando a requisição carrega uma sessão AAM válida. Um usuário que passa pela autenticação via uma rota mal configurada não pode receber acidentalmente credenciais de backend injetadas; uma requisição anônima sempre alcança o backend sem injeção.
Início de sessão Kerberos — o utilizador do Windows é reconhecido sem pedir palavra-passe
Um navegador associado ao domínio negoceia SPNEGO com o gateway e o utilizador entra com a conta Windows que já tem — sem segunda palavra-passe e sem portal adicional. A partir daí o backend recebe a identidade através da forma de injeção que compreende, pelo que uma aplicação antiga ganha início de sessão único silencioso sem tocar numa linha do seu código. A delegação de identidade para o backend em nome do utilizador está deliberadamente fora de âmbito: prende o gateway a um modelo de confiança de domínio que a maioria dos parques está a abandonar, e as formas de injeção cobrem a mesma necessidade com um raio de impacto muito menor.
NTLM publicado de forma transparente — o parque antigo continua a funcionar
As aplicações Windows antigas que negoceiam NTLM são publicadas sem modificação. A plataforma reconhece o esquema, marca a ligação como privada — nunca é partilhada nem reequilibrada — e fixa-a ao servidor que emitiu o desafio; é exatamente isso que permite ao NTLM sobreviver a um proxy. Sem agente no servidor, sem reescrita, sem exceções na firewall.
Profundidade operacional
Os mecanismos que tornam a injeção em nível de header segura na borda de acesso.
Empilhamento de condições seguro quanto à precedência em tempo de compilação
As condições por injeção se compõem com as outras decisões baseadas em ACL do gateway (estado de autenticação, política de acesso, seleção de backend). O compilador de condições usa um padrão de extra-entries para que as condições de injeção sempre sejam avaliadas após autenticação e política, nunca antes — uma regra por injeção não pode acidentalmente inverter o resultado de uma decisão de política de precedência superior.
Buscas de variável de frontend condicionais via dispatcher
Quando uma injeção precisa de um valor que não está no saco de sessão — um valor derivado de uma busca por requisição (expansão de grupo, pesquisa de atributo) — o dispatcher emite uma busca condicional que é executada apenas quando a condição da injeção corresponde. Backends que nunca recebem uma injeção nunca pagam o custo de buscar o valor.
Detecção de sessão perdida do backend com assinatura de resposta configurável
Cada serviço pode declarar a assinatura de resposta que significa "minha sessão acabou" — um código de status específico, um header de resposta específico, um marcador de corpo. Quando o gateway vê essa assinatura, define um sinalizador de sessão perdida, limpa a sessão do lado do gateway e redireciona conforme a política configurada.
Limpeza de logout iniciado pelo backend e cadeia de redirecionamento
Quando o próprio backend desconecta o usuário — tipicamente respondendo com uma assinatura de logout conhecida — o gateway executa uma limpeza em três etapas: limpar os cookies do lado do gateway, excluir o registro da sessão e redirecionar via o alvo configurado. A precedência logout-wins garante que esse caminho supere qualquer injeção em andamento.
Tratamento de valores criptografados, nunca registrados em texto claro
Credenciais e tokens usados por injeções são armazenados criptografados no repositório de configuração e nunca são escritos nos logs de acesso em texto claro. As entradas de auditoria registram que uma injeção foi executada em uma requisição, não qual valor ela carregou. Os operadores veem a política; o payload no fio fica no fio.
Reautenticação silenciosa quando a sessão do backend se perde
Quando um backend perde a sua própria sessão e a sessão do AAM ainda é válida, o gateway restabelece-a em segundo plano com um 302 para o daemon do AAM em vez de devolver o utilizador a uma página de login — o utilizador não vê nada. O logout viaja também no sentido inverso: sair do gateway envia um sinal de logout a cada backend que recebeu uma identidade injetada.
Onde as equipes usam
SSO moderno sobre o portal de intranet existente
Um portal interno que confiou no X-Remote-User por uma década continua lendo X-Remote-User. O gateway executa SAML/OIDC moderno na borda, depois injeta o mesmo header que sempre viu. Sem deploy do backend, sem corte de migração.
Authorization-Bearer na frente de microsserviços
Um cluster de microsserviços internos quer autenticação com Bearer token, mas não quer executar um fluxo de identidade por serviço. O gateway emite um token assinado por requisição e o injeta; cada serviço verifica o token com as chaves do gateway.
Um login, muitos formatos de autenticação do backend
Uma implantação multi-aplicação inclui uma aplicação que quer Basic Auth, uma que quer um header personalizado e uma que quer um cookie. Um gateway AAM lida com o login uma vez; cada backend recebe o formato que espera, simultaneamente, com condições por rota.
Propagação de identidade de qualidade de auditoria
Regimes de conformidade que exigem uma cadeia de identidade clara — "quem estava autenticado quando esta requisição chegou ao backend" — obtêm essa cadeia produzida pelo fluxo de auditoria do gateway. Valores de header, condições de injeção e o sujeito autenticado são registrados juntos.
Perguntas frequentes
Como isso funciona sem alterar o código do backend?
E se um usuário enviar seu próprio header X-Auth-User para se passar por outra identidade?
O gateway pode enviar uma asserção SAML assinada para um backend que espera uma por requisição?
O que acontece quando a sessão do backend expira, mas a sessão do AAM ainda é válida?
Um gateway AAM pode executar diferentes formatos de injeção para diferentes backends ao mesmo tempo?
SSO moderno na frente, autenticação legada no backend
Implantaremos o Backend SSO nas suas aplicações reais — mantendo seus modelos de confiança existentes, removendo a credencial das mãos do usuário e produzindo uma cadeia de identidade de qualidade de auditoria para cada requisição.