Une passerelle en bois traverse une eau calme vers la rive opposée dans la brume matinale.

Notes produit

Connecter sans conserver les mots de passe

Vos mots de passe sont déjà dans Active Directory. Comment ajouter une connexion moderne sans copier leurs empreintes ni exposer un nouveau point d’entrée ? C’est le rôle d’Authrim Relay.

Partir de ce qui ne peut pas changer

Les comptes des salariés sont dans Active Directory. Les règles de mot de passe, leur expiration et les départs y sont gérés depuis des années.

Vous souhaitez ajouter les clés d’accès, organiser l’authentification multifacteur et étendre le SSO aux SaaS. La première question est toujours la même : où vérifier le mot de passe ?

Certaines configurations synchronisent les empreintes de mots de passe vers le cloud ; d’autres demandent à l’annuaire interne de les vérifier. Il faut savoir où vivent les données d’authentification, qui ouvre la connexion et qui exploite ce chemin.

WordWarden laisse la vérification à LDAP/AD et permet de choisir le chemin. Authrim Relay propose une connexion sortante aux organisations qui ne veulent pas publier de nouveau point d’entrée.

Le rôle de WordWarden

Authrim WordWarden est un connecteur d’annuaire, un petit service placé près de LDAP/AD. Il reçoit un nom d’utilisateur et un mot de passe, interroge l’annuaire et renvoie le résultat.

L’interface de connexion, les sessions, les clés d’accès, les codes e-mail, la fédération, la corrélation d’audit et la correspondance des identités restent gérés par Authrim. WordWarden effectue la vérification près de l’annuaire.

Le sens de la connexion change la configuration réseau et les composants à exploiter.

Qui ouvre la connexion ?

WordWarden propose trois modes, selon que votre réseau doit ou non publier un point d’entrée.

VOTRE RÉSEAU AUTHRIM (CLOUD) LIMITE Direct HTTPS WordWarden point d’entrée public requis Authrim Authrim ouvre la connexion vers le point d’entrée Cloudflare Tunnel WordWarden + cloudflared hôte non exposé directement Authrim cloudflared ouvre la connexion via le tunnel Cloudflare Authrim Relay WordWarden connexion sortante uniquement Authrim Relay (Durable Object) WordWarden ouvre la connexion, sans entrée publique
Les flèches montrent qui ouvre la connexion. Direct HTTPS part d’Authrim vers un point d’entrée publié. Tunnel et Relay partent tous deux du réseau interne : Tunnel utilise le processus cloudflared, tandis que WordWarden maintient lui-même la connexion Relay.

Quel mode convient à votre environnement ?

Pour un nouveau déploiement sans nouvel accès entrant, examinez d’abord Relay. Une infrastructure de publication ou un tunnel existant peut aussi être pertinent. Les exemples suivants décrivent des configurations possibles, pas des références clients.

Authrim Relay : garder AD en interne sans ajouter d’entrée

Prenez une entreprise où tout nouveau serveur public doit être approuvé, ou une université qui interdit les connexions entrantes vers le réseau LDAP du campus. WordWarden se connecte à Authrim sans publier de nouveau port entrant sur ce réseau.

Ni nouveau point d’entrée public ni processus de tunnel séparé. Les connexions WebSocket sortantes doivent être autorisées ; WordWarden et sa connexion restent à surveiller. Relay ne convient pas à un réseau interdisant toute communication externe.

Cloudflare Tunnel : reprendre une exploitation déjà en place

Si une équipe exploite déjà cloudflared et ses routes pour publier des outils internes, WordWarden peut suivre les mêmes procédures sans ouvrir de nouveau port entrant.

Il faut configurer le nom d’hôte et le chemin permettant aux requêtes d’Authrim d’atteindre le connecteur, et maintenir le tunnel. L’hôte interne n’accepte pas directement de connexions entrantes ; les requêtes passent par Cloudflare.

Direct HTTPS : utiliser une plateforme d’API existante

Une entreprise, une université ou un institut de recherche peut déjà exploiter une DMZ et un proxy inverse pour ses échanges externes. Un point HTTPS accessible depuis Authrim peut alors s’intégrer aux procédures de certificats, de journalisation et de supervision existantes.

Aucune connexion de tunnel ou Relay à maintenir. En contrepartie, l’organisation autorise le chemin entrant et protège le point d’entrée public. Elle publie l’interface HTTPS du connecteur, pas le port LDAP/AD directement sur Internet.

Dans tous les cas, WordWarden doit pouvoir joindre LDAP/AD. Le statut d’établissement académique ne détermine pas le choix : l’infrastructure et la politique réseau, oui.

Authrim Relay : une connexion qui part de l’intérieur

En mode Relay, WordWarden se connecte à Authrim par WebSocket depuis votre réseau. WebSocket garde une connexion ouverte pour permettre aux deux côtés d’échanger des messages.

WordWarden attend sur cette connexion. Lors d’une connexion, Authrim demande : « Vérifiez cet utilisateur. » WordWarden interroge l’annuaire interne et renvoie le résultat par le même chemin.

C’est comme appeler depuis votre organisation et rester en ligne : l’autre personne peut aussi parler. Aucune nouvelle connexion entrante n’est nécessaire à chaque demande.

Le réseau de l’annuaire ne publie donc aucune URL pour ce mode. Cela évite de gérer un nouveau nom public, un certificat et un WAF pour le connecteur. L’autorisation de sortie, la maintenance et la surveillance de la connexion restent nécessaires.

Détail technique : WebSocket et ouverture d’un port entrant

La différence tient à l’initiateur de la connexion. En Direct HTTPS, l’organisation expose un point qu’Authrim peut joindre. Avec Relay, WordWarden ouvre une connexion WebSocket chiffrée (wss) vers Authrim.

Un pare-feu à états ou un NAT suit généralement les connexions ouvertes de l’intérieur et laisse passer leur trafic de retour. WordWarden peut ainsi recevoir des demandes sans publier de port entrant ni configurer de redirection pour de nouvelles connexions externes.

Des ports sont toujours utilisés. Une connexion wss utilise normalement le port TCP 443 à destination. Le pare-feu ou proxy doit autoriser la sortie vers Relay et les connexions WebSocket durables. Tant que la connexion est coupée, aucune demande ne peut arriver par ce chemin ; sa surveillance reste nécessaire.

Réduire les points d’entrée n’élimine pas les requêtes reçues sur la connexion établie. L’authentification du pair et la validation des requêtes restent indispensables.

Référence : protocole WebSocket (RFC 6455)

Une connexion sortante doit aussi être authentifiée. Relay vérifie le connecteur et la destination configurée.

Détail technique : authentification par HMAC

WordWarden répond par HMAC à un défi de courte durée, en signant une chaîne contenant l’identifiant du défi et un nonce. Il vérifie aussi que les identifiants du tenant et du connecteur dans l’URL correspondent à sa configuration.

HMAC est obligatoire dans les trois modes. Relay réduit l’exposition entrante, sans supprimer l’authentification du connecteur ni la gestion des secrets.

Ce qui traverse réellement la frontière

Il faut être précis : le mot de passe peut quitter le réseau interne.

Saisi dans l’interface de connexion, il transite par Authrim. La promesse exacte est : Authrim et WordWarden ne le stockent pas, et non qu’il ne sort jamais.

VOTRE RÉSEAU AUTHRIM (CLOUD) Le mot de passe passe à gauche, sans être stocké LDAP / AD autorité LDAP WordWarden Authrim Utilisateur Résultat et attributs autorisés reviennent à Authrim STOCKÉ autorité LDAP NON STOCKÉ (WordWarden / Authrim) mot de passe ou empreinte même importée d’un ancien système Authrim conserve sessions, profil et clés d’accès
La documentation le précise : Authrim ne doit ni importer, ni hacher, ni rehacher, ni conserver les mots de passe, y compris leurs empreintes issues d’un système existant.

La réponse est limitée elle aussi

En cas de succès, Authrim reçoit le résultat et les attributs demandés qui figurent dans la liste d’autorisation locale du connecteur. C’est le côté annuaire qui décide ce qu’il transmet, pas le demandeur.

Une modification du seul côté Authrim ne peut donc pas élargir les informations extraites du réseau.

Le mot de passe comme étape de transition

Cette intégration sert la transition.

LDAP/AD reste la référence des mots de passe. Les utilisateurs gardent leur compte habituel pendant l’enregistrement progressif des clés d’accès. Le code e-mail reste un moyen de récupération. Le parcours continue de fonctionner pendant l’évolution de la méthode.

La documentation interdit explicitement d’exporter les empreintes LDAP/AD vers Authrim. Ce serait créer une copie des données d’authentification au lieu d’organiser la transition.

Bêta publique en préparation. Première cible : v0.1.0-beta.1.

Destiné aux pilotes dans des organisations capables d’exploiter un service près de LDAP/AD et de gérer annuaire, réseau, TLS et secrets. Ce n’est pas un annuaire managé.

Nécessite Authrim 0.3.2 ou ultérieur, avec Directory Authentication et Relay activés. La bêta actuelle demande un redémarrage du processus lors d’un changement de configuration.

Copier les données d’authentification ou ouvrir une entrée
ne sont pas les seules possibilités.

Vérifier près de l’annuaire et ouvrir la connexion vers l’extérieur permet de proposer une connexion moderne sans copier les empreintes de mots de passe ni publier de point entrant dans le réseau interne.

L’objectif est ensuite le passage aux clés d’accès. L’intégration à l’annuaire fournit l’appui nécessaire pour avancer sans interrompre la connexion des utilisateurs.