Embora o OIDC seja cada vez mais usado em aplicações modernas, o SAML 2.0 ainda é um padrão crítico em integrações de identidade corporativa e governamental. Muitas organizações executam seus diretórios existentes atrás de AD FS, Entra ID, Okta, Ping, Auth0 ou um gateway de federação via SAML. No lado público, as federações de identidade nacionais e os serviços SaaS conectados a elas também costumam ser construídos sobre SAML 2.0.
Por isso, a abordagem correta para uma aplicação nova ou modernizada não é criar uma base de usuários separada. A aplicação deve conectar-se ao provedor de identidade no qual a organização já confia. Para isso, a camada de acesso precisa atuar como provedor de serviços SAML 2.0: deve redirecionar o usuário ao IdP correto, validar a resposta SAML recebida, extrair a identidade com segurança e convertê-la em uma sessão que a aplicação possa usar.
No entanto, a integração SAML não é apenas "pegar o XML, ler o usuário, abrir a sessão". Quando implementada incorretamente, produz graves vulnerabilidades de segurança. A assinatura na resposta SAML deve ser validada corretamente, deve-se verificar qual elemento foi de fato assinado e devem-se impedir ataques como remoção de assinatura ou inserção de asserção forjada. A janela de validade, a restrição de audience, a informação de issuer, o formato de NameID e os mapeamentos de atributos não devem apenas ser lidos; devem ser aplicados com rigor.
O lado operacional é igualmente importante. Atualizar os metadados do IdP, rotação de certificados e chaves de assinatura, roteamento de IdP diferente por tenant, regras de mapeamento diferentes para aplicações diferentes e fluxos de Single Logout não são pequenos detalhes adicionados depois. São partes fundamentais para que a federação SAML funcione de forma segura e sustentável.
Um dos erros mais comuns é embutir uma biblioteca SAML separada em cada aplicação. Essa abordagem distribui a responsabilidade da identidade por cada backend. Uma alteração de IdP exige atualização separada em muitas aplicações. MFA, acesso condicional, confiança de dispositivo, comportamento de logout e registros de auditoria são resolvidos novamente para cada aplicação. O resultado não é identidade centralizada, mas uma confusão de identidade distribuída.
O lugar correto é a borda de acesso. SAML deve ser terminado em um único ponto; deve ser gerenciado na mesma camada que autenticação, MFA, acesso condicional, confiança de dispositivo e Backend SSO. Assim as aplicações não carregam a complexidade do protocolo de federação; recebem apenas uma identidade verificada, limpa e confiável.
Gerenciar SAML corretamente não é apenas conectar-se a um IdP. É verificar a confiança de identidade da organização em um único ponto, auditá-la e entregá-la às aplicações com segurança.
Um único gateway AAM termina o SAML corretamente na borda; o restante do motor de acesso assenta sobre isso.
AuthnRequest assinado na saída, validação completa de asserção na entrada — assinatura, audience, janela de validade, AudienceRestriction, formato de NameID. Os bindings HTTP-Redirect e HTTP-POST são ambos suportados. O processamento de assinatura segue as regras de conformidade SAML 2.0 existentes para derrotar ataques SAML conhecidos.
Um único gateway AAM pode rotear aplicações diferentes para IdPs diferentes e tenants diferentes da mesma aplicação para IdPs diferentes, simultaneamente. A seleção de IdP é feita por requisição a partir do contexto da aplicação — sem gateway separado por IdP, sem seletor manual de página de login para o usuário.
Regras de mapeamento por IdP convertem o NameID e as declarações de atributos da asserção SAML para os campos canônicos que o restante do AAM usa — nome de usuário, e-mail, grupos, nome de exibição, atributos personalizados. O mesmo mapeamento alimenta o gating de MFA, as expressões de acesso condicional, os logs de auditoria e as injeções de Backend SSO.
Uma autenticação SAML não funciona isoladamente — ela é orquestrada junto com MFA na borda (se o IdP não aplicou step-up), expressões de acesso condicional, avaliação contínua de confiança e injeção de Backend SSO em direção ao backend. A asserção SAML torna-se uma entrada para a sessão AAM; não é a sessão inteira.
SP SAML 2.0 conforme aos padrões mais os recursos operacionais que tornam a federação segura e gerenciável em escala.
O usuário chega à aplicação, o AAM redireciona ao IdP configurado com um SAML AuthnRequest assinado, o usuário faz login no IdP e o IdP retorna a asserção assinada ao endpoint Assertion Consumer Service do AAM. Para a requisição de saída suporta-se o binding HTTP-Redirect e para a asserção de entrada o binding HTTP-POST.
Para implantações em que o ponto de partida do usuário é o IdP — uma rampa de lançamento de portal no IdP, um catálogo de aplicações, um portal de identidade governamental — o SSO iniciado por IdP é aceito. O RelayState carrega o destino da aplicação alvo; assim, o usuário chega à página correta depois que a asserção é consumida.
A assinatura da asserção é verificada contra o certificado de assinatura do IdP configurado; a audience corresponde ao identificador do SP AAM configurado; NotBefore e NotOnOrAfter definem a janela de validade; AudienceRestriction é aplicada. Ataques SAML conhecidos (signature wrapping, signature stripping, NotBefore drift) são derrotados explicitamente em vez de tolerados silenciosamente.
Quando o IdP criptografa a asserção (xmlenc), o AAM descriptografa a asserção com a chave privada do SP configurada antes da validação. Asserções criptografadas são comuns para federação de identidade governamental e para IdPs que não querem que o conteúdo da asserção seja legível na camada de binding. As chaves de criptografia são armazenadas criptografadas no repositório de configuração e nunca registradas em log.
Cada IdP pode ser configurado com um formato de NameID preferido (persistent, transient, email-address, unspecified) e um mapeamento dos nomes de atributos SAML para os campos de sessão AAM. IdPs diferentes podem apresentar a identidade de forma diferente — uma claim de número de identificação nacional, um e-mail, um identificador opaco único — e ainda assim produzir o mesmo formato de sessão canônico do AAM.
Um único gateway AAM que mantém muitos tenants à frente pode rotear cada tenant para seu próprio IdP. A seleção é feita no momento da requisição a partir do contexto da aplicação ou do tenant — sem gateway separado por IdP, sem seletor por usuário. O mesmo gateway pode carregar a federação de identidade governamental para um tenant e um IdP corporativo personalizado para outro, simultaneamente.
Quando o IdP inicia um logout, o AAM aceita o SAML LogoutRequest, encerra a sessão AAM e sinaliza aos backends que recebem injeção de Backend SSO. Quando a aplicação inicia o logout, o AAM envia um LogoutRequest assinado ao IdP e aguarda o LogoutResponse antes de declarar a sessão encerrada. O SLO front-channel é suportado.
Single Logout baseado em SOAP back-channel, o perfil SAML ECP (Enhanced Client/Proxy) para clientes sem navegador e a confirmação de sujeito holder-of-key para integrações de alta segurança estão no roadmap. O objeto de configuração e o restante do pipeline do SP já os acomodam; o que falta é o código específico do protocolo.
A mecânica que mantém uma federação SAML segura, atualizada e observável.
Os metadados do IdP podem ser carregados fazendo upload do XML de metadados fornecido pelo IdP, configurando uma URL de metadados que o AAM busca e armazena em cache, ou inserindo manualmente endpoints e certificados. A configuração manual é a opção realista para IdPs que não publicam metadados conformes aos padrões; onde funcionam, os outros dois métodos são preferidos.
O AAM publica seu próprio documento de metadados de SP em uma URL estável; assim, o operador do IdP pode importá-lo para o repositório de confiança do IdP em vez de transferir endpoints e certificados manualmente. Os metadados refletem a configuração ativa do SP — a URL ACS atual, o certificado de assinatura atual, o endpoint SLO atual.
As chaves de assinatura e os certificados do SP têm vida limitada. O AAM suporta rotação de chaves com sobreposição — durante a janela de rollover, tanto a chave antiga quanto a nova são validadas contra os metadados do IdP em cache. Os operadores planejam a rotação com antecedência; o runtime aceita ambas durante o período de sobreposição e a rotação entra em vigor de forma limpa.
As asserções carregam timestamps NotBefore e NotOnOrAfter. Relógios reais derivam; o AAM aplica uma janela de tolerância configurável; assim, um pequeno desvio não rejeita asserções válidas, e desvios grandes (indicadores de má configuração ou replay) ainda são rejeitados. A tolerância é por IdP; um IdP bem sincronizado recebe uma janela estreita, um IdP problemático recebe uma permissão documentada.
Cada evento SAML — AuthnRequest de saída, asserção de entrada, resultado de verificação de assinatura, LogoutRequest de SLO, LogoutResponse — é registrado com um ID de correlação que se reconecta à sessão AAM, ao(s) backend(s) por trás dela e à identidade do usuário. A pergunta "quem entrou por qual IdP e quando" é respondida com uma única consulta.
A atualização automática periódica dos metadados do IdP a partir da URL configurada, a detecção de diferenças e o alerta ao operador em alterações de certificado de assinatura estão no roadmap. A telemetria de rotação — métricas de idade de chave, alerta de dias até a expiração, agendamento automático de rollover — também está planejada.
Aplicações que precisam aceitar um IdP de federação de identidade nacional — típico para implantações governamentais, setores regulamentados e serviços SaaS contratados por compradores públicos. O AAM termina a federação SAML na borda e apresenta uma identidade limpa e verificada à aplicação por trás dela.
IdPs corporativos existentes que já são autoritativos para a força de trabalho. O AAM conecta-se como um SP SAML sem pedir à equipe de IdP que altere nada. Novas aplicações entram na federação adicionando um registro ao AAM, não adicionando uma nova biblioteca SAML a cada base de código.
Aplicações SaaS onde cada cliente traz seu próprio IdP. Um único gateway AAM mantém todos os tenants à frente; o tráfego de cada tenant é roteado para o IdP daquele tenant. Adicionar um tenant não é uma implantação; é adicionar um registro de IdP ao repositório de configuração.
Alguns IdPs autenticam mas não aplicam step-up MFA ou acesso condicional — especialmente gateways de federação antigos. O AAM aceita a autenticação do IdP e então assenta seu próprio MFA, expressões de acesso condicional e avaliação contínua de confiança sobre isso antes de conceder acesso à aplicação.
Vamos conectar o AAM ao seu IdP — corporativo ou de federação de identidade governamental — e assentar o restante do motor de acesso sobre a asserção com MFA, acesso condicional, confiança de dispositivo e Backend SSO.