L'architecture d'identité des organisations modernes n'est pas homogène. Tandis qu'une équipe utilise un annuaire central, une autre unité métier peut dépendre d'un ancien système d'authentification basé sur RADIUS, un groupe d'utilisateurs externes d'une identité sociale, et une application de service public d'une identité publique nationale. Dans les projets fintech, santé et secteur public, les services d'identité REST personnalisés sont également fréquents.
Les plateformes d'accès traditionnelles traitent souvent cette diversité au cas par cas. Chaque fournisseur génère une intégration différente, une piste d'audit différente, un comportement d'erreur différent et un flux MFA différent. Au final, la politique de sécurité se fragmente ; l'opérateur doit gérer le même utilisateur de manière différente selon les systèmes.
Les systèmes legacy constituent un problème distinct. Remplacer une infrastructure d'authentification RADIUS ou Web Form en service depuis des années est à la fois coûteux et risqué. Pourtant, sans ajouter une couche de MFA, d'accès conditionnel, de lockout, de contrôle d'IP et d'audit devant ces systèmes, il n'est pas possible d'atteindre un niveau zero-trust moderne.
Les API d'identité personnalisées révèlent la même lacune. Si le système d'authentification client, d'OTP ou d'identité mobile propre à l'organisation expose un endpoint HTTP, la plateforme d'accès doit pouvoir l'utiliser comme fournisseur d'identité. Sinon, chaque application doit écrire sa propre intégration.
TR7 AAM réunit différents modèles de fournisseurs d'identité dans une seule couche de fournisseur d'authentification ; il relie les fournisseurs RADIUS, OAuth2, HTTP API, Web Form, LocalDB et Portal au même moteur d'accès, de MFA et d'audit.
TR7 AAM fait fonctionner différentes sources d'identité sous un seul modèle de fournisseur et porte chaque résultat d'authentification vers la même chaîne de décision d'accès.
Les fournisseurs RADIUS, OAuth2, HTTP API, Web Form, LocalDB et Portal sont définis comme le même type d'objet fournisseur. Le moteur de flux traite chaque fournisseur de la même manière, avec les transitions de succès, d'erreur, de lockout et de MFA.
Avec la prise en charge de PAP et CHAP, les backends RADIUS existants peuvent être placés derrière AAM. Le système d'authentification existant est préservé ; on lui ajoute MFA, accès conditionnel, lockout et audit.
Les fournisseurs OAuth2 intégrés et les configurations OAuth2 personnalisées peuvent être reliés à AAM. Des scénarios comme la restriction de domaine Google Workspace et le mapping des champs d'une identité publique nationale sont intégrés à un seul moteur d'accès.
Le service d'identité REST, le système d'OTP ou l'endpoint d'authentification client propre à l'organisation peut être utilisé comme fournisseur AAM. En configurant la méthode, les headers, le body et les conditions de succès, le besoin de développement supplémentaire est réduit.
Les intégrations de fournisseurs d'identité supplémentaires portent vers le modèle de sécurité commun d'AAM différentes sources d'identité, des systèmes d'authentification legacy aux API REST personnalisées.
TR7 AAM prend en charge les types d'authentification PAP et CHAP côté RADIUS. PAP offre une compatibilité legacy plus simple ; CHAP offre un comportement d'authentification basé sur challenge. L'infrastructure RADIUS existante peut être placée devant AAM sans être remplacée. C'est une voie de modernisation pratique pour les systèmes télécom, NAC, anciens VPN et accès d'entreprise.
Une clé secrète partagée distincte peut être définie pour chaque backend RADIUS. Ainsi, la relation d'authentification entre AAM et le serveur RADIUS est séparée par fournisseur. Dans les environnements multi-RADIUS, chaque intégration possède sa propre frontière de sécurité. Les changements opérationnels sont gérés via une seule configuration centrale.
Plusieurs serveurs RADIUS peuvent être définis sous un fournisseur. Si le serveur principal ne répond pas, le serveur secondaire peut prendre le relais. Cette structure fonctionne avec un comportement de timeout court et de bascule rapide adapté à la nature UDP de RADIUS. Le système d'identité legacy se rapproche d'un modèle de haute disponibilité.
Le fournisseur Google OAuth2 peut être restreint à un domaine Workspace spécifique. Ainsi, seuls les utilisateurs du domaine appartenant à l'organisation peuvent se connecter. Les comportements access type et prompt peuvent être configurés selon le flux OAuth2. L'identité sociale externe devient contrôlée par la politique d'accès d'entreprise.
Le fournisseur OAuth2 d'identité publique nationale fonctionne avec des mappings de champs intégrés pour les scénarios d'identité publique. Des champs tels que numéro d'identité, prénom, nom, e-mail, téléphone et date de naissance peuvent être portés vers l'objet utilisateur AAM. Le flux avec PKCE renforce la sécurité de l'authentification. Dans les applications de service public, l'identité citoyenne est reliée à la chaîne d'accès AAM.
En mode Custom OAuth2, les URL d'authorization, de token, de userinfo, de logout et de revocation peuvent être définies séparément. Client ID, secret, scope, response type, grant type et comportement PKCE peuvent être configurés. Ainsi, les systèmes d'identité d'entreprise personnalisés parlant l'OAuth2 standard sont intégrés à AAM. L'intégration est gérée au sein du modèle de fournisseur unique.
Certaines anciennes applications n'offrent pas de protocole standard ; elles n'ont qu'un formulaire de connexion web. TR7 AAM peut définir, via le fournisseur web form, l'URL de connexion, les champs du formulaire et les conditions de succès. Le succès peut être détecté par le comportement de redirection, de cookie ou de status code. Ainsi, l'écran de connexion d'une ancienne application peut être pris dans la chaîne de contrôle AAM.
Le fournisseur HTTP API transforme n'importe quel endpoint REST en source d'authentification. Les méthodes GET, POST ou PUT ; les types de body JSON, multipart, URL-encoded ou raw peuvent être utilisés. La condition de succès peut être évaluée via le status code, la présence d'un cookie ou l'URL de redirection. Les systèmes d'OTP bancaire, d'authentification client ou de vérification mobile personnalisée peuvent être reliés avec ce modèle.
Le fournisseur LocalDB utilise un dépôt d'utilisateurs local géré au sein d'AAM. Il convient aux environnements sans connexion Internet, aux systèmes de test, aux comptes de partenaires externes ou aux accès indépendants du dépôt d'identité central. Des contrôles de sécurité de base comme l'historique des mots de passe peuvent être appliqués. Cela facilite les scénarios d'usage autonome et self-hosted.
Le fournisseur Portal peut utiliser la gateway d'un autre portail AAM comme source d'authentification. Cette structure prend en charge les scénarios de transition de type SSO entre plusieurs portails ou différentes portes d'accès. L'utilisateur est authentifié dans une seule chaîne AAM et peut être porté vers d'autres points d'accès. Dans les grands déploiements d'entreprise, cela simplifie l'architecture de portail.
Chaque fournisseur peut renvoyer des noms de champs différents. Avec userMapping, TR7 mappe les valeurs des source attributes sur les champs standard d'AAM. Par exemple, le numéro d'identité, l'e-mail, le groupe, le téléphone ou le display name sont portés vers l'objet utilisateur commun. Le MFA, l'accès conditionnel et l'injection SSO vers le backend fonctionnent via cet objet standard.
Chaque fournisseur d'authentification peut hériter, étendre ou override son propre comportement de lockout. Ainsi, des fournisseurs comme RADIUS, HTTP API ou LocalDB peuvent avoir un seuil de tentatives échouées différent. La protection contre le brute force ne se coince pas dans un seul réglage global. La politique est déterminée selon le profil de risque du fournisseur d'identité.
Les fournisseurs d'identité supplémentaires doivent être conçus conjointement avec le comportement de protocole, l'accès réseau, le mapping utilisateur, la gestion des connexions échouées et les pistes d'audit.
RADIUS fonctionne sur UDP ; il n'a pas la logique classique de pool de connexions TCP. Les valeurs de timeout doivent être courtes et le comportement de failover rapidement planifié. Si plusieurs serveurs RADIUS sont définis, le temps de réponse et l'ordre doivent être choisis avec soin.
Dans les flux OAuth2, le state et le PKCE réduisent les risques de CSRF et de rejeu. Dans les scénarios axés sur le secteur public ou le mobile, le comportement PKCE est particulièrement important. Lors de la configuration du fournisseur, des hypothèses sécurisées doivent être préservées.
Le fournisseur HTTP API n'est pas obligé de ne regarder que le status code. Des conditions de succès supplémentaires comme la présence d'un cookie ou l'URL de redirection peuvent être utilisées. Cela permet de s'adapter aux différents comportements de succès des services d'identité personnalisés.
Des entrées utilisateur ou des variables AAM peuvent être utilisées dans le path, le body, les headers HTTP et les champs Web Form. Le nom d'utilisateur, l'OTP ou d'autres champs de saisie peuvent être ajoutés dynamiquement à la requête d'identité. Ce comportement doit être utilisé avec une validation soigneuse.
Certains types de fournisseurs doivent sortir par le bon domaine réseau pour atteindre le fournisseur d'identité externe. Les fournisseurs OAuth2, OIDC ou Web Form peuvent nécessiter différentes route tables. La sélection réseau par fournisseur est critique pour le succès de l'intégration.
Chaque tentative de fournisseur doit être écrite dans le journal d'audit avec un résultat réussi, échoué ou verrouillé. Le type de fournisseur, l'utilisateur, l'IP source et l'information de résultat peuvent être transférés vers le SIEM. Cela assure un audit unifié dans une infrastructure d'identité fragmentée.
Un ancien système d'authentification RADIUS en service dans un environnement télécom ou FAI est préservé. Placé devant TR7 AAM, on lui ajoute MFA, accès conditionnel et audit central.
Un portail municipal ou public peut effectuer la connexion citoyenne via l'OAuth2 d'identité publique nationale. Les champs d'identité sont portés dans la session AAM et l'accès au service est géré par les règles d'accès conditionnel.
Différentes régions ou équipes peuvent utiliser différents systèmes d'identité. TR7 AAM réunit ces fournisseurs sous une seule gateway et un seul modèle d'audit.
Si le service d'authentification client ou d'OTP d'une banque expose une API REST, AAM peut l'appeler comme fournisseur HTTP. Le succès est vérifié par la condition de status code, de cookie ou de redirection.
Les comptes de partenaires qui ne seront pas intégrés à l'annuaire d'entreprise central peuvent être gérés dans LocalDB d'AAM. Une politique de MFA, de lockout et d'accès distincte est appliquée à ces comptes.
Faites fonctionner RADIUS, OAuth2, HTTP API et la base d'utilisateurs locale dans le même flux d'accès conditionnel, de MFA et d'audit. Examinons cela ensemble dans une installation en direct sur votre propre environnement.