La arquitectura de identidad de las organizaciones modernas no es homogénea. Mientras un equipo usa un directorio centralizado, otra unidad de negocio puede necesitar un antiguo sistema de autenticación basado en RADIUS, un grupo de usuarios externo una identidad social, y una aplicación de servicio público una identidad pública nacional. En proyectos fintech, sanitarios y del sector público también son habituales los servicios REST de identidad personalizados.
Las plataformas de acceso tradicionales suelen abordar esta diversidad por separado. Para cada proveedor surge una integración distinta, un rastro de auditoría distinto, un comportamiento de error distinto y un flujo de MFA distinto. Como resultado, la política de seguridad se fragmenta; el operador se ve obligado a gestionar al mismo usuario de forma distinta en distintos sistemas.
Los sistemas legacy son un problema aparte. Reemplazar la infraestructura de autenticación basada en RADIUS o web form que lleva años funcionando es caro y arriesgado. Pero sin añadir una capa de MFA, acceso condicional, lockout, control de IP y auditoría delante de estos sistemas, no es posible alcanzar el nivel zero-trust moderno.
Las API de identidad personalizadas muestran el mismo vacío. Si el propio sistema de verificación de clientes, OTP o identidad móvil de la organización expone un endpoint HTTP, la plataforma de acceso debe poder usarlo como proveedor de identidad. De lo contrario, cada aplicación se ve obligada a escribir su propia integración.
TR7 AAM unifica los distintos modelos de proveedor de identidad en una sola capa de authentication provider; conecta los proveedores RADIUS, OAuth2, HTTP API, Web Form, LocalDB y Portal al mismo motor de acceso, MFA y auditoría.
TR7 AAM ejecuta las distintas fuentes de identidad bajo un único modelo de proveedor y lleva cada resultado de autenticación a la misma cadena de decisión de acceso.
Los proveedores RADIUS, OAuth2, HTTP API, Web Form, LocalDB y Portal se definen como el mismo objeto de proveedor. El motor de flujo procesa cada proveedor de la misma manera con sus transiciones de éxito, error, lockout y MFA.
Con soporte de PAP y CHAP, los servicios backend RADIUS existentes pueden situarse detrás de AAM. El sistema de autenticación existente se conserva; encima se añaden MFA, acceso condicional, lockout y auditoría.
Los proveedores OAuth2 integrados y las configuraciones OAuth2 personalizadas pueden conectarse a AAM. Escenarios como la restricción de dominio de Google Workspace y el mapeo de atributos de identidad pública nacional se incluyen en un solo motor de acceso.
El propio servicio REST de identidad, sistema OTP o endpoint de verificación de clientes de la organización puede usarse como proveedor de AAM. Configurando el método, las cabeceras, el cuerpo y las condiciones de éxito, se reduce la necesidad de desarrollo adicional.
Las Integraciones de Proveedores de Identidad Adicionales llevan distintas fuentes de identidad, desde sistemas de autenticación legacy hasta API REST personalizadas, al modelo de seguridad común de AAM.
TR7 AAM soporta los tipos de autenticación PAP y CHAP en el lado RADIUS. PAP aporta una compatibilidad legacy más sencilla; CHAP ofrece un comportamiento de autenticación basado en challenge. La infraestructura RADIUS existente puede situarse delante de AAM sin reemplazarla. Esta es una vía práctica de modernización para telco, NAC, antiguas VPN y sistemas de acceso corporativo.
Para cada servicio backend RADIUS puede definirse una clave compartida distinta. Así la relación de autenticación entre AAM y el servidor RADIUS se separa por proveedor. En entornos con múltiples RADIUS, cada integración tiene su propio límite de seguridad. Los cambios operativos se gestionan desde una sola configuración centralizada.
Bajo un proveedor pueden definirse varios servidores RADIUS. Si el servidor primario no responde, el secundario puede entrar en acción. Esta estructura funciona con un comportamiento de timeout corto y conmutación rápida acorde con la naturaleza basada en UDP de RADIUS. El sistema de identidad legacy se acerca más a un modelo de alta disponibilidad.
El proveedor de Google OAuth2 puede limitarse a un dominio de Workspace concreto. Así se garantiza que solo inicien sesión los usuarios del dominio propio de la organización. Los comportamientos de access type y prompt pueden configurarse según el flujo OAuth2. La identidad social externa se vuelve controlada por la política de acceso corporativo.
El proveedor OAuth2 de identidad pública funciona con mapeos de atributos integrados para escenarios de identidad pública nacional. Atributos como número de identificación, nombre, apellidos, e-mail, teléfono y fecha de nacimiento pueden trasladarse al objeto de usuario de AAM. El flujo con soporte de PKCE refuerza la seguridad de la autenticación. En aplicaciones que prestan servicio público, la identidad del ciudadano se conecta a la cadena de acceso de AAM.
En el modo Custom OAuth2 pueden definirse por separado authorization URL, token URL, userinfo URL, logout URL y revocation URL. El client ID, secret, scope, response type, grant type y el comportamiento de PKCE son configurables. Así, los sistemas de identidad corporativos personalizados que hablan OAuth2 estándar se incluyen en AAM. La integración se gestiona dentro de un solo modelo de proveedor.
Algunas aplicaciones antiguas no ofrecen un protocolo estándar; solo tienen un formulario de login web. TR7 AAM puede definir, con el proveedor web form, la login URL, los campos del formulario y las condiciones de éxito. El éxito puede determinarse por el comportamiento de redirect, cookie o status code. Así, la pantalla de inicio de sesión de una aplicación antigua puede incluirse en la cadena de control de AAM.
El proveedor HTTP API convierte cualquier endpoint REST en una fuente de autenticación. Pueden usarse los métodos GET, POST o PUT; los tipos de cuerpo JSON, multipart, URL-encoded o raw. La condición de éxito puede evaluarse mediante status code, presencia de cookie o redirect URL. Sistemas de OTP bancario, verificación de clientes o verificación móvil personalizada pueden conectarse con este modelo.
El proveedor LocalDB utiliza el repositorio de usuarios local gestionado dentro de AAM. Es adecuado para entornos sin conexión a internet, sistemas de prueba, cuentas de partners externos o accesos independientes del repositorio de identidad centralizado. Pueden aplicarse controles de seguridad básicos como el historial de contraseñas. Esto facilita los escenarios de uso independiente y self-hosted.
El proveedor Portal puede usar otro portal gateway de AAM como fuente de autenticación. Esta estructura soporta escenarios de transición tipo SSO entre múltiples portales o distintas puertas de acceso. El usuario se autentica en una sola cadena AAM y puede trasladarse a otros puntos de acceso. En grandes despliegues corporativos simplifica la arquitectura de portales.
Cada proveedor puede devolver nombres de atributos distintos. Con el userMapping de TR7, los valores de los source attribute se mapean a los campos estándar de AAM. Por ejemplo, el número de identificación, el e-mail, el grupo, el teléfono o el display name se trasladan a un objeto de usuario común. El MFA, el acceso condicional y la inyección de SSO al servicio backend funcionan sobre este objeto estándar.
Cada authentication provider puede heredar, ampliar o sobrescribir su propio comportamiento de lockout. Así, proveedores como RADIUS, HTTP API o LocalDB pueden tener un umbral distinto de inicios de sesión fallidos. La protección contra fuerza bruta no queda encajonada en un solo ajuste global. La política se determina según el perfil de riesgo del proveedor de identidad.
Los proveedores de identidad adicionales deben diseñarse junto con el comportamiento del protocolo, el acceso de red, el mapeo de usuario, la gestión de inicios fallidos y los rastros de auditoría.
RADIUS funciona sobre UDP; no tiene la lógica clásica de pool de conexiones TCP. Los valores de timeout deben planificarse cortos y el comportamiento de failover rápido. Si se definen varios servidores RADIUS, el tiempo de respuesta y el orden deben elegirse con cuidado.
En los flujos OAuth2, state y PKCE reducen los riesgos de CSRF y replay. En escenarios orientados a lo público o a lo móvil, el comportamiento de PKCE es especialmente importante. Al configurar el proveedor deben preservarse supuestos seguros.
El proveedor HTTP API no tiene por qué fijarse solo en el status code. Pueden usarse condiciones de éxito adicionales como la presencia de cookie o la redirect URL. Esto se adapta a los distintos comportamientos de éxito de los servicios de identidad personalizados.
En los campos de HTTP path, body, header y Web Form pueden usarse entradas del usuario o variables de AAM. El nombre de usuario, el OTP u otros campos de entrada pueden añadirse dinámicamente a la solicitud de identidad. Este comportamiento debe usarse con una validación cuidadosa.
Algunos tipos de proveedor deben salir por el dominio de red correcto para acceder al proveedor de identidad externo. Los proveedores OAuth2, OIDC o Web Form pueden necesitar distintas tablas de rutas. La selección de red por proveedor es crítica para el éxito de la integración.
Cada intento de proveedor debe escribirse en el audit log con sus resultados de éxito, fallo o bloqueo. El tipo de proveedor, el usuario, la IP de origen y la información de resultado pueden exportarse a SIEM. Esto aporta una auditoría unificada en una infraestructura de identidad fragmentada.
El antiguo sistema de autenticación RADIUS que funciona en un entorno telco o ISP se conserva. Situándolo delante de TR7 AAM, se añaden MFA, acceso condicional y auditoría centralizada.
Un portal municipal o del sector público puede hacer el inicio de sesión del ciudadano con OAuth2 de identidad pública nacional. Los atributos de identidad se trasladan a la sesión de AAM y el acceso al servicio se gestiona con reglas de acceso condicional.
Distintas regiones o equipos pueden usar distintos sistemas de identidad. TR7 AAM unifica estos proveedores bajo un solo gateway y un solo modelo de auditoría.
Si el servicio de verificación de clientes u OTP del banco ofrece una API REST, AAM puede invocarlo como proveedor HTTP. El éxito se valida mediante condición de status code, cookie o redirect.
Las cuentas de partners que no se incorporarán al directorio corporativo centralizado pueden gestionarse en la LocalDB de AAM. A estas cuentas se les aplica MFA, lockout y política de acceso aparte.
Ejecute RADIUS, OAuth2, HTTP API y la base de datos de usuarios local en el mismo flujo de acceso condicional, MFA y auditoría. Lo revisamos en una instalación en vivo en su propio entorno.