Comprendre le fonctionnement de l'Agent de poste
Présentation générale
L'Agent de poste Olfeo SaaS est un composant logiciel clé d'Olfeo SaaS.
Pensé pour être quasiment invisible de vos utilisateurs, c'est pourtant lui qui assure l'orientation du trafic et qui permet à vos utilisateurs d'utiliser Internet en toute sécurité.
En effet, lorsqu'il est installé sur le poste d'un utilisateur, l'Agent agit comme un proxy local sur le poste et route vers la plateforme Olfeo SaaS le trafic HTTP / HTTPS de cet utilisateur ou en direct, selon les paramètres que vous avez définis. En insérant un jeton d'authentification propre à l'utilisateur, il permet ainsi d'authentifier les requêtes faites par l'utilisateur pour éviter les usages non-autorisés et permettre la traçabilité de la navigation et l'application de règles de filtrages fines basées sur l'identité.
Déploiement de l'agent et gestion de droits
L'Agent nécessite des droits administrateur sur le poste pour être installé, supprimé ou appliquer les modifications de configuration réseau nécessaires à son foncitonnement.
Pour éviter que vos utilisateurs ne puissent contourner la protection d'Olfeo SaaS , assurez-vous que vos utilisateurs ne disposent pas des privilèges nécessaires pour inhiber/contourner son action et veillez à configurer les clients HTTP (navigateurs internet ou autres) de façon appropriée.
Plus d'infos sur les cas d'usages documentés par ici.
Principes de fonctionnement
Quelque soit le mode d'installation choisi, lors de l'installation L'Agent de poste va récupérer depuis la plateforme et installer sur le poste :
Les procédures d'installation sont décrites ci-dessous (voir Installer l'agent de poste).
les binaires nécessaires au fonctionnement de l'Agent de poste (l'Agent lui même ainsi que son systray, le service de communication avec l'utilisateur)
les fichiers de configuration de l'Agent
les certificats d'autorité de Olfeo SaaS nécessaires pour la validation de la chaine TLS suite au déchiffrement.
Astuce
Vous n'avez donc pas besoin de déployer manuellement les certificats d'autorité nécessaires au déchiffrement, l'Agent s'en charge pour vous et les insère dans le magasin de certificats du système. Leur mise à jour est également prise en charge par l'Agent.
la configuration de routage attachée à la configuration d'Agent de poste que vous aurez définie (voir ci-dessous Créer une configuration d'Agent de poste).
L'Agent se lance automatiquement à l'issue de l'installation et lors des redémarrages des postes. Il nécessite des droits d'administrateur pour pouvoir être installé/désinstallé.
L'authentification fonctionne en s'appuyant sur le principe de SAML, Olfeo SaaS agissant comme un fournisseur de service (Service Provider ou SP) et reposant sur votre solution de fourniture d'identité (Identity Provider ou IDP) comme source de vérité pour l'authentification de vos utilisateurs.
Une fois l'Agent installé, la séquence d'authentification se déroule comme présenté sur la figure ci-dessous :
 |
L'authentification des requêtes de l'utilisateur (une fois son identité confirmée par votre IDP) repose sur des JWT. L'Agent authentifie les requêtes via un jeton d'accès à durée de vie courte (access token) qu'il rafraîchit régulièrement (15mn) à l'aide d'un jeton de rafraîchissement à vie plus longue (refresh token). Le renouvellement de ce dernier nécessite une confirmation de l'identité par votre IDP et se fait par défaut tous les 7 jours (voir ici pour Gérer l'expiration des jetons d'authentification).
Ces jetons contiennent l'identité de l'utilisateur ainsi que des éléments nécessaires à la détermination du contexte de filtrage. Ils sont signés de sorte à ce qu'une altération de leur contenu les rende invalides.
Important
Ré-authentification
La réauthentification "transparente" repose sur le principe suivant. Lorsque le jeton de rafraîchissement expire, l'Agent, avant de traiter la requête elle-même, redirige la requête du navigateur vers votre IDP auquel il redonne alors les crédences d'accès via un cookie. Pour que la réauthentification transparente fonctionne il faut donc que les deux conditions suivantes soient remplies :
le navigateur doit être ouvert
l'utilisateur doit avoir souhaité rester connecté lors de sa première authentification et que son navigateur ait stocké le cookie associé (pas en navigation privée par ex.) - exemple ci-dessous
Révocation anticipée des jetons d'authentification
Dans certains cas, les jetons de rafraîchissement d'authentification peuvent être révoqués avant leur expiration programmée. Cela peut se produire notamment :
Si l'Agent n'arrive pas à contacter le service d'authentification de Olfeo SaaS suite à un trop grand nombre d'échecs
Suite à la survenue d'évènement structurants apportés à vos utilisateurs dans votre annuaire, en particulier dans les cas :
de suppression ou de désactivation d'un utilisateur : ainsi il s'écoule de fait au plus 15 mn entre la désactivation/suppression d'un utilisateur et son impossibilité de naviguer avec Olfeo SaaS,.
de changement de groupe d'un utilisateur : ainsi, il s'écoule là aussi au plus 15 mn avant que le jeton ne soit rafraîchi et que son nouveau contexte de filtrage (et donc des règles de filtrage potentiellement différentes le cas échéant) lui soient appliquées.
L’Agent de poste permet à plusieurs utilisateurs distincts d’utiliser le service Olfeo SaaS sur un même poste, chacun bénéficiant alors de son contexte de filtrage et d’une journalisation individualisée.
Ainsi si Bob ouvre une session avec ses identifiants sur le poste d’Alice, lorsqu’il voudra se connecter à Internet, il devra s’authentifier sur Olfeo SaaS et sera protégé avec les politiques s’appliquant à son contexte et son historique de navigation sera bien journalisé dans Olfeo SaaS avec son identifiant (et non plus avec ceux d’Alice).
Sous windows notamment, un certain nombre de processus système et réseau (LocalNetworkServices par ex.) sont assimilés à des utilisateurs authentifiés par le système lui-même et les requêtes HTTP faites par ces processus et services passent donc par l'Agent. Dans ce cadre, l'Agent assimile un nombre limité de ces processus au dernier utilisateur "humain" à s'être authentifié sur le poste.
Régulièrement, l'Agent vérifie auprès de la plateforme si certains composants essentiels à son fonctionnement (fichier de configuration, certificats d'autorité) ont été mis à jour : si c'est le cas, ceux-ci sont téléchargés automatiquement et instantanément pris en compte sans intervention nécessaire.
Cette recherche de mise à jour de configuration est faite par défaut toutes les 30mn.
De même, l'Agent interroge régulièrement la plateforme pour savoir si une mise à jour des binaires est disponible. Le cas échéant, il télécharge le binaire le plus récent de façon sécurisée et effectue la mise à jour en arrière-plan sans interruption de service pour vos utilisateurs.
Cette recherche est faite toutes les 30mn.
Echecs de la mise à jour
Dans des conditions de faible bande passante, l'Agent peut ne pas parvenir à récupérer la totalité du binaire dans un délai imparti. L'Agent met alors fin à la procédure de mise à jour de façon transparente pour l'utilisateur et tente à nouveau ultérieurement de récupérer la mise à jour.
Dans ces conditions spécifiques, il est alors nécessaire de mettre à jour manuellement l'Agent en utilisant l'installeur à télécharger depuis l'interface d'administration.
Olfeo SaaS Lite fonctionne légèrement différemment d'Olfeo SaaS : dans ce mode d'usage, l’Agent contrôle alors les réglages DNS du poste. Il redirige les requêtes DNS avec une information d'authentification de l'utilisateur vers Olfeo SaaS Lite ou les résout en direct, selon les paramètres que vous avez définis.
Apprenez en plus sur Olfeo SaaS Lite.
Il n'y a pas de redirection automatique vers l'IDP lorsque vos utilisateurs ne sont pas (encore) authentifiés.
Pour que vos utilisateurs s'authentifient pour utiliser Olfeo SaaS Lite, il est possible d'utiliser la commande "Se connecter" dans le menu de l'Agent accessible depuis la zone de notification de l'OS.
 |
Lancer automatiquement la page de connexion
Il est possible de lancer automatiquement la connexion à la page d'authentification en scriptant l'accès à https://localhost:8090/login.
Contactez notre équipe Support ou Consulting pour en savoir plus.
Olfeo SaaS Lite n'est pas compatible avec les portails captifs.
Olfeo SaaS Lite ne supporte pas le multi sessions.
Prérequis à l'utilisation de l'Agent de poste par vos utilisateurs dans votre organisation
L'Agent de poste doit être considéré comme autorisé par votre EDR / XDR à être exécuté avec des privilèges administrateur pour que son fonctionnement ne soit pas entravé.
Le dossier contenant les données de configuration et ces fichiers ne doivent pas être altérés par vos outils d'EDR/XDR.
Ports réservés pour l'Agent
L'Agent doit pouvoir communiquer localement sur les ports 3128 et 8090.
Assurez-vous que ces ports soient bien disponibles sur les postes de vos utilisateurs. Le cas échéant, n'hésitez pas à contacter notre équipe Support.
Autoriser l'accès au réseau local pour Chrome et Edge
Une option de sécurité introduite dans les navigateurs Google Chrome et Microsoft Edge (tous deux basés sur Chromium) peut restreindre l’accès aux ressources du réseau local. Cette option, nommée Local Network Access Check, peut empêcher l’Agent de fonctionner correctement si elle est désactivée ou si l’utilisateur refuse l’autorisation.
Avertissement
Pour garantir le bon fonctionnement du processus d’authentification, cette option doit impérativement être activée. L’absence d’autorisation vous empêchera de vous authentifier via l’Agent.
Étapes d’activation
Ouvrez votre navigateur (Chrome ou Edge).
Allez à la page suivante :
Chrome : chrome://flags/#local-network-access-check enable.
Edge : edge://flags/#local-network-access-check
Recherchez l’option Local
Network Access Check.Sélectionnez
Disableddans le menu déroulant.Redémarrez le navigateur pour appliquer les modifications.
Automatisation de la configuration
Vous pouvez automatiser cette configuration via une GPO. Apprenez-en plus à ce sujet dans notre base de connaissance..
L'ouverture des destinations par ports suivantes dans vos pare-feux est requise pour permettre le passage du trafic
Par définition, l'accès aux ressources d'authentification n'est pas "proxifié" par notre plateforme, l'Agent doit donc pouvoir identifier qu'il n'a pas accès à internet mais pas d'accès autorisé à notre plateforme, puis il doit ensuite pouvoir négocier une authentification avec votre IDP.
L'accès non-proxifié aux ressources suivantes est automatiquement inclus dans le proxypac mais les ressources suivantes doivent également être autorisées dans vos pare-feux :
Usage d'un fournisseur d'identité autre qu'Entra ID (ex Azure AD)
Vous utilisez un AD on-premises avec un ADFS : Il vous appartient de définir dans votre proxy.pac Olfeo SaaS les points de terminaisons publics de votre entreprise à ne pas proxyfier pour que vos utilisateurs puissent s'identifier et s'authentifier sur votre ADFS. Reportez-vous à cette section de la documentation pour voir comment faire pour ajouter une destination au proxy.pac.