A arquitetura de identidade das organizações modernas não é homogênea. Enquanto uma equipe usa um diretório central, outra unidade de negócio pode precisar de um antigo sistema de validação baseado em RADIUS, um grupo de usuários externos de uma identidade social, e uma aplicação de serviço público de uma identidade governamental. Em projetos de fintech, saúde e setor público, serviços de identidade REST personalizados também são frequentes.
As plataformas de acesso tradicionais muitas vezes tratam essa diversidade separadamente. Para cada provedor surge uma integração diferente, uma trilha de auditoria diferente, um comportamento de erro diferente e um fluxo de MFA diferente. Como resultado, a política de segurança se fragmenta; o operador é obrigado a gerenciar o mesmo usuário de formas diferentes em sistemas diferentes.
Os sistemas legados são um problema à parte. Substituir uma infraestrutura de validação baseada em RADIUS ou web form que funciona há anos é caro e arriscado. Mas, sem adicionar uma camada de MFA, acesso condicional, lockout, controle de IP e auditoria à frente desses sistemas, não é possível elevar-se ao nível moderno de zero trust.
As APIs de identidade personalizadas mostram a mesma lacuna. Se o sistema próprio de validação de cliente, OTP ou identidade móvel da organização oferece um endpoint HTTP, a plataforma de acesso deve poder usá-lo como provedor de identidade. Caso contrário, cada aplicação é obrigada a escrever sua própria integração.
O TR7 AAM unifica os diferentes modelos de provedor de identidade em uma única camada de authentication provider; conecta os provedores RADIUS, OAuth2, HTTP API, Web Form, LocalDB e Portal ao mesmo motor de acesso, MFA e auditoria.
O TR7 AAM opera diferentes fontes de identidade sob um único modelo de provedor e leva cada resultado de validação à mesma cadeia de decisão de acesso.
Os provedores RADIUS, OAuth2, HTTP API, Web Form, LocalDB e Portal são definidos como o mesmo objeto de provedor. O motor de fluxo processa cada provedor da mesma forma, com as transições de sucesso, erro, lockout e MFA.
Com suporte a PAP e CHAP, os backends RADIUS existentes podem ser colocados atrás do AAM. O sistema de validação existente é preservado; sobre ele adicionam-se MFA, acesso condicional, lockout e auditoria.
Provedores OAuth2 integrados e configurações OAuth2 personalizadas podem ser conectados ao AAM. Cenários como a restrição de domínio Google Workspace e o mapeamento de campos de identidade governamental são incluídos em um único motor de acesso.
O serviço de identidade REST próprio da organização, o sistema OTP ou o endpoint de validação de cliente podem ser usados como provedor AAM. Configurando method, header, body e condições de sucesso, reduz-se a necessidade de desenvolvimento adicional.
As Integrações de Provedor de Identidade Adicionais levam diferentes fontes de identidade — de sistemas de validação legados a APIs REST personalizadas — ao modelo de segurança comum do AAM.
O TR7 AAM suporta os tipos de validação PAP e CHAP no lado RADIUS. O PAP oferece compatibilidade legada mais simples; o CHAP oferece comportamento de validação baseado em desafio. A infraestrutura RADIUS existente pode ser colocada à frente do AAM sem ser substituída. Esse é um caminho prático de modernização para sistemas de telco, NAC, VPN antiga e acesso corporativo.
Pode-se definir um segredo compartilhado separado para cada backend RADIUS. Assim, a relação de validação entre o AAM e o servidor RADIUS é separada por provedor. Em ambientes com múltiplos RADIUS, cada integração tem seu próprio limite de segurança. As mudanças operacionais são gerenciadas por uma única configuração central.
Sob um provedor, pode-se definir mais de um servidor RADIUS. Se o servidor primário não responder, o servidor secundário pode entrar em ação. Essa estrutura opera com comportamento de timeout curto e transição rápida, adequado à natureza UDP do RADIUS. O sistema de identidade legado aproxima-se de um modelo de alta disponibilidade.
O provedor Google OAuth2 pode ser restringido a um domínio Workspace específico. Assim, garante-se que apenas usuários do domínio da organização façam login. Os comportamentos de access type e prompt podem ser configurados conforme o fluxo OAuth2. A identidade social externa torna-se controlada pela política de acesso corporativa.
O provedor OAuth2 de identidade governamental opera com mapeamentos de campo integrados para cenários de identidade do setor público. Campos como número de identificação, nome, sobrenome, e-mail, telefone e data de nascimento podem ser levados ao objeto de usuário AAM. O fluxo com suporte a PKCE aumenta a segurança da autenticação. Em aplicações de serviço público, a identidade do cidadão vincula-se à cadeia de acesso do AAM.
No modo OAuth2 personalizado, authorization URL, token URL, userinfo URL, logout URL e revocation URL podem ser definidos separadamente. Client ID, secret, scope, response type, grant type e o comportamento de PKCE podem ser configurados. Assim, sistemas de identidade corporativos personalizados que falam OAuth2 padrão são incluídos no AAM. A integração é gerenciada dentro de um único modelo de provedor.
Algumas aplicações antigas não oferecem protocolo padrão; têm apenas um formulário de login web. O TR7 AAM, com o provedor web form, pode definir login URL, campos do formulário e condições de sucesso. O sucesso pode ser interpretado pelo comportamento de redirect, cookie ou status code. Assim, a tela de login da aplicação antiga pode ser colocada na cadeia de controle do AAM.
O provedor HTTP API transforma qualquer endpoint REST em fonte de autenticação. Podem ser usados os métodos GET, POST ou PUT; os tipos de body JSON, multipart, URL-encoded ou raw. A condição de sucesso pode ser avaliada por status code, presença de cookie ou redirect URL. Sistemas de OTP bancário, validação de cliente ou validação móvel personalizada podem ser conectados por esse modelo.
O provedor LocalDB usa o repositório de usuários local gerenciado dentro do AAM. É adequado para ambientes sem conexão à internet, sistemas de teste, contas de parceiros externos ou acessos independentes do repositório de identidade central. Controles de segurança básicos como histórico de senha podem ser aplicados. Isso facilita cenários de uso independente e self-hosted.
O provedor Portal pode usar outro gateway de portal AAM como fonte de autenticação. Essa estrutura suporta cenários de transição semelhantes a SSO entre múltiplos portais ou diferentes portas de acesso. O usuário é validado em uma única cadeia AAM e pode ser transportado a outros pontos de acesso. Em grandes implantações corporativas, simplifica a arquitetura de portais.
Cada provedor pode retornar nomes de campo diferentes. Com o userMapping do TR7, os valores dos source attributes são mapeados para os campos padrão do AAM. Por exemplo, número de identificação, e-mail, grupo, telefone ou display name são transferidos para o objeto de usuário comum. MFA, acesso condicional e injeção de SSO no backend operam por esse objeto padrão.
Cada authentication provider pode herdar, estender ou sobrescrever seu próprio comportamento de lockout. Assim, provedores como RADIUS, HTTP API ou LocalDB podem ter limiares diferentes de tentativas de login mal-sucedidas. A proteção contra brute force não fica presa a uma única configuração global. A política é definida conforme o perfil de risco do provedor de identidade.
Os provedores de identidade adicionais devem ser projetados em conjunto com o comportamento de protocolo, o acesso de rede, o mapeamento de usuário, a gestão de logins mal-sucedidos e as trilhas de auditoria.
O RADIUS opera sobre UDP; não tem a lógica clássica de pool de conexões TCP. Os valores de timeout devem ser curtos e o comportamento de failover planejado de forma rápida. Se mais de um servidor RADIUS for definido, o tempo de resposta e a ordem devem ser escolhidos com cuidado.
Nos fluxos OAuth2, state e PKCE reduzem os riscos de CSRF e replay. Em cenários voltados ao setor público ou móvel, o comportamento de PKCE é especialmente importante. Ao configurar o provedor, devem-se preservar pressupostos seguros.
O provedor HTTP API não precisa olhar apenas o status code. Condições de sucesso adicionais como presença de cookie ou redirect URL podem ser usadas. Isso adapta-se aos diferentes comportamentos de sucesso dos serviços de identidade personalizados.
Nos campos de HTTP path, body, header e Web Form podem ser usadas entradas do usuário ou variáveis do AAM. Nome de usuário, OTP ou outros campos de entrada podem ser adicionados dinamicamente à solicitação de identidade. Esse comportamento deve ser usado com validação cuidadosa.
Alguns tipos de provedor precisam sair pela área de rede correta para acessar o provedor de identidade externo. Provedores OAuth2, OIDC ou Web Form podem precisar de route tables diferentes. A seleção de rede por provedor é crítica para o sucesso da integração.
Cada tentativa de provedor deve ser escrita no log de auditoria com os resultados de sucesso, falha ou bloqueio. Tipo de provedor, usuário, IP de origem e informação de resultado podem ser transferidos ao SIEM. Isso proporciona auditoria unificada em uma infraestrutura de identidade fragmentada.
O antigo sistema de validação RADIUS que opera em ambiente de telco ou ISP é preservado. Colocando o TR7 AAM à frente, adicionam-se MFA, acesso condicional e auditoria central.
Um portal municipal ou público pode fazer o login do cidadão via OAuth2 de identidade governamental. Os campos de identidade são transferidos à sessão AAM e o acesso ao serviço é gerenciado por regras de acesso condicional.
Diferentes regiões ou equipes podem usar sistemas de identidade diferentes. O TR7 AAM unifica esses provedores sob um único gateway e um único modelo de auditoria.
Se o serviço de validação de cliente ou OTP do banco oferece uma API REST, o AAM pode chamá-la como provedor HTTP. O sucesso é validado por status code, cookie ou condição de redirect.
Contas de parceiros que não serão incluídas no diretório corporativo central podem ser gerenciadas no LocalDB do AAM. A essas contas aplicam-se MFA, lockout e política de acesso separados.
Opere RADIUS, OAuth2, HTTP API e banco de dados de usuários local no mesmo fluxo de acesso condicional, MFA e auditoria. Vamos examinar com uma configuração ao vivo no seu próprio ambiente.