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.
Um objeto de configuração por backend, cinco formatos de injeção, coordenados com o restante do motor de acesso.
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.
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.
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.
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.
Cinco formatos de injeção em produção, a disciplina de remoção de entrada que os torna seguros, mais o roadmap para injeções de protocolo superior.
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.
Para aplicações legadas que se autenticam via HTTP Basic, o gateway injeta Authorization: Basic
Para backends que já falam Bearer tokens (APIs internas, microsserviços, aplicações de intranet modernas) o AAM injeta Authorization: Bearer
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.
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.
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.
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.
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.
Formatos de injeção de protocolo superior — delegação restrita Kerberos para backends que requerem um ticket de serviço, NTLM para ambientes Windows mais antigos — estão no roadmap. O objeto de configuração e a infraestrutura condicional já os acomodam; o runtime específico de protocolo é o trabalho que resta.
Os mecanismos que tornam a injeção em nível de header segura na borda de acesso.
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.
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.
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.
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.
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.
Um fluxo de re-autenticação silenciosa que usa um 302 para o daemon do AAM para reestabelecer uma sessão de backend sem redirecionar o usuário para uma página de login está no roadmap. A propagação de logout iniciada pelo AAM — enviar um sinal de logout para cada backend que recebeu uma identidade injetada — também está no roadmap.
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.
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.
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.
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.
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.