Ce billet présente une fonction de la prochaine version 4.8.0 de S-Filer Portal™: l’authentification déléguée. C’est la première étape d’une feuille de route visant à prendre en charge des scénarios d’authentification plus avancés, comme l’authentification à deux facteurs et la fédération d’identité.
L’objectif de cette fonction est de permettre à S-Filer Portal de mieux s’intégrer aux solutions de gestion des accès Web (Web Access Management, ou WAM). Ces solutions sont habituellement déployées dans les grandes entreprises pour gérer le flux d’authentification des différentes applications Web selon les politiques de l’organisation. Elles prennent généralement en charge de nombreux scénarios avancés (authentification à deux facteurs, appareils mobiles reconnus, OAuth, SAML, authentification renforcée), puis transmettent l’identité authentifiée à l’application Web située derrière. Autre aspect important: elles permettent une authentification unique à l’échelle de l’entreprise pour toutes les applications Web qu’elles protègent, ce qui améliore considérablement l’expérience utilisateur. Les clients qui disposent d’une solution WAM peuvent désormais s’en servir et activer tous ces scénarios avancés avec S-Filer Portal.
Cette fonction s’appelle authentification déléguée parce que S-Filer Portal délègue à la solution WAM la tâche d’authentifier l’utilisateur, puis fait confiance à l’identité qu’elle lui transmet. La fonction porte essentiellement sur le mécanisme par lequel la solution WAM peut transmettre cette identité à S-Filer Portal. Voici comment cela fonctionne:
Étape 1
L’utilisateur effectue une requête pour accéder à S-Filer Portal. La requête est reçue par un serveur Web, typiquement Microsoft IIS ou Apache HTTPD. Sur ce serveur Web est installé un agent WAM qui intercepte la requête.
Étape 2
L’agent WAM envoie la requête au serveur WAM pour inspection. Typiquement, l’un de ces scénarios se produit:
- L’utilisateur est déjà authentifié et la requête porte un témoin reconnu par la solution WAM;
- L’utilisateur n’est pas authentifié: la solution WAM demande alors à l’agent de présenter une page de connexion. Une fois l’utilisateur authentifié, le témoin WAM est établi pour les requêtes suivantes.
La solution WAM renvoie à l’agent l’identité de l’utilisateur authentifié, accompagnée de quelques informations supplémentaires.
Étape 3
Dans la configuration WAM de l’application S-Filer Portal, les paramètres indiquent d’établir deux variables d’en-tête HTTP. Dans la première (nommée SFILER_USER), l’agent inscrit l’identifiant de compte de l’utilisateur authentifié; pour les comptes Active Directory, il s’agit typiquement du samAccountName. Dans la seconde (nommée SFILER_DOMAIN), il inscrit une constante représentant l’identifiant du domaine d’authentification correspondant à l’Active Directory. Cette valeur provient de la configuration de S-Filer.
Lorsque S-Filer est configuré pour l’authentification déléguée, il fait confiance aux valeurs de ces en-têtes. Il est donc d’une importance critique de s’assurer que l’agent inscrit TOUJOURS ces valeurs et empêche ces en-têtes de provenir de la requête d’origine. De plus, des mesures réseau, comme des pare-feux, doivent être mises en place afin que seul le serveur Web hébergeant l’agent WAM puisse communiquer avec le port Web de la passerelle S-Filer. Sinon, quelqu’un pourrait se connecter directement à ce port, envoyer une requête portant les bons en-têtes et s’authentifier comme n’importe quel utilisateur du système en connaissant simplement son samAccountName.
Étape 4
La passerelle émettra vers le serveur S-Filer une requête d’authentification particulière, appelée requête d’authentification déléguée. Cette requête contient le nom d’utilisateur, l’identifiant de domaine et l’adresse IP du client tels que reçus dans les en-têtes. Elle est également signée avec la clé privée de la passerelle S-Filer. À la réception, le serveur vérifie la signature à l’aide de la clé publique de la passerelle (qu’il conserve dans sa base de données) et vérifie aussi que l’authentification déléguée est activée pour cette passerelle. Si tout est conforme, il émet un jeton d’authentification et la suite se déroule exactement comme si l’utilisateur s’était authentifié par mot de passe.
Considérations de sécurité
Cette fonction apporte plus de puissance et de souplesse, mais sa configuration exige un grand soin, car elle comporte aussi des risques. Cette section met en évidence les mesures obligatoires à mettre en place pour l’utiliser de façon sécuritaire.
- La solution WAM ou le serveur Web doit être configuré de manière à écarter les en-têtes d’authentification déléguée (SFILER_USER, SFILER_DOMAIN) s’ils sont présents dans la requête provenant du client. Il peut ensuite les établir lui-même avec l’identité authentifiée, ou laisser passer la requête sans en-têtes pour que S-Filer authentifie l’utilisateur par mot de passe.
- Le port Web de la passerelle S-Filer ne doit accepter que les connexions provenant du serveur Web sur lequel l’agent WAM est installé. Typiquement, on installe le serveur Web et son agent WAM sur le même serveur que la passerelle S-Filer, puis on bloque au pare-feu toute requête vers le port Web de la passerelle qui ne provient pas de « localhost ».
- Comme toujours, toutes les communications réseau devraient se faire par TLS afin de protéger les données en transit.
Configuration de S-Filer
Voici comment l’authentification déléguée se configure dans l’interface de configuration de S-Filer.
- Dans l’interface de configuration, sélectionnez l’interface Web pour laquelle l’authentification déléguée doit être activée;
- Sélectionnez ensuite « Fonctionnalités »;
- Activez enfin l’authentification déléguée et choisissez les noms des en-têtes HTTP servant à transmettre l’identité.
Conclusion
Voilà tout ce qu’il y a à savoir sur cette nouvelle fonction. Comme mentionné plus haut, elle offre beaucoup de puissance et de souplesse, mais elle doit être utilisée avec soin pour ne pas introduire de vulnérabilités.
