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é.
Par mesure de sécurité, l'Agent nécessite des droits administrateur sur le poste pour être installé, supprimé ou appliquer des modifications de configuration proxy.
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.
le fichier proxy.pac attaché à 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 rafraichissement 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.
Régulièrement, l'Agent vérifie auprès de la plateforme si la configuration d'Agent de poste a été mise à jour : si c'est le cas, elle est téléchargée automatiquement et instantanément prise en compte.
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.
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).
Prérequis à l'utilisation de l'Agent de poste par vos utilisateurs sur votre réseau
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.