Documentation technique Olfeo SaaS

Cette nouvelle version inclut des correctifs mineurs et prépare la connectivité avec des infrastructures plus distribuées, ainsi-que l'usage d'un nouveau certificat pour signer l'installeur (MSI).

Si vous disposez de procédures d'installation et de déploiement automatisées (exemple: par GPO), il est recommandé de les modifier en utilisant la dernière version de l'installeur téléchargeable depuis l'interface d'administration (en savoir plus).

Le multi-session est désormais disponible sur MacOS en version 2.6.

La fonction de diagnostics embarqués s’enrichit de nouveau dans la 2.6. Elle supporte maintenant le multi-session et inclut :

Le diagnostic embarqué indiquait parfois l’erreur « Failed to resolve DNS » de manière erronée à cause d’un problème de cache. Cela a été corrigé.

Le téléchargement automatique de la dernière version de l’agent était impossible pour les connexions à faible bande passante. Cela était dû à un timeout trop court, nous avons augmenté sa durée.

Le jeton d’authentification était parfois supprimé à tort, ce qui entrainait des réauthentifications prématurées. Cela a été corrigé.

Vous avez été nombreux à nous le demander : l’Agent de poste permet à présent à 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).

Rappel : lorsqu’un agent est installé sur un poste Windows, la connexion au service Olfeo SaaS se fait dans son navigateur. Chaque utilisateur d’une session Windows est amené à se connecter puis naviguer. Cette navigation passe par la solution Olfeo SaaS en utilisant les règles correspondantes à chaque utilisateur et les journaux de navigation sont historisés par utilisateur. Une autre fonction joliment enrichie !

Dans certains cas de figure, vous pouvez être amenés à souhaiter « désactiver » l’Agent de poste sans pour autant le désinstaller, il est maintenant possible de désactiver et de réactiver l’Agent de poste sans devoir le désinstaller.

Pour limiter son usage à tort, cette fonctionnalité n’est utilisable qu’avec des droits d’administration sur le poste et n’est disponible qu’en ligne de commande.

Les commandes suivantes ont été ajoutées à l’Agent de poste :

Exemple:

PS C:\Windows\system32> cd C:\"Program files"\trustlane
PS C:\Program files\trustlane> .\trustlane_authentication_agent.exe proxy status
Proxy is : enabled
PS C:\Program files\trustlane> .\trustlane_authentication_agent.exe proxy disable
INFO : 2023/09/05 21:13:29.220512 logger.go:57: [2.5.3]: UnSetProxyParameter
PS C:\Program files\trustlane> .\trustlane_authentication_agent.exe proxy status
Proxy is : disabled
PS C:\Program files\trustlane> .\trustlane_authentication_agent.exe proxy enable
INFO : 2023/09/06 07:59:03.398111 proxy_parametrize_windows.go:32: [2.5.3]: SetProxyParameter PAC: https://storage.gra.cloud.ovh.net/v1/AUTH_d988-some-random-string-here-c264/preprod-pub/e97d s0m3-rand0m-str1ng-here-90/2.pac 
PS C:\Program files\trustlane> .\trustlane_authentication_agent.exe proxy status
Proxy is : enabled

Rappel : par défaut l’Agent de poste est localisé dans le système aux chemins suivants :

Améliorée en 2.3, la fonction de diagnostics embarqués s’enrichit de nouveau dans la 2.5 incluant maintenant la date du diagnostic et quelques améliorations graphiques mineures.

La communication avec l’IDP n’est désormais plus vérifiée pour les tests de continuité de service. Jusqu’à présent, lors de la vérification de la disponibilité de la plateforme, l’Agent de poste suivait les redirections jusqu’à atteindre l’IDP. En cas d’indisponibilité de l’IDP cela provoquait à tort la désactivation de la proxyfication et masquait un problème d’authentification.

Introduite en 2.2, la fonction de diagnostics embarqués s'améliorer dans la 2.3 (et ce n'est pas fini !).

Dans cette version, le look'n feel des résultats s'est nettement amélioré et adopte à présent l'identité visuelle d'Olfeo SaaS.

Les informations sur le jeton d'authentification sont également affichées : sa date d'émission et -le cas échéant- sa date de dernière invalidation et le motif d'invalidation, pour vous permettre de mieux appréhender les remontées de vos utilisateurs. Plus d'informations à ce sujet par ici.

Dans certains cas spécifiques, l'Agent ne peut plus accéder normalement aux informations d'authentification contenues dans le keyring (effacement par un logiciel tiers, manipulation ou altération par l'utilisateur ou un programme...).

Dans ce cas, l'Agent n'est plus bloqué et redirigera automatiquement l'utilisateur sur la mire d'authentification de votre IDP pour obtenir un nouveau jeton valide, sans qu'une réinstallation soit nécessaire.

La mise à l'image vers notre nouvelle identité se poursuit : au survol de l'icône de l'Agent dans le systray (ou barre des programmes sous MacOS), l'infobulle affiche désormais "Agent d'authentification Olfeo SaaS"

NB : le nom technique de l'Agent lui-même (i.e le service windows) reste pour l'instant avec notre ancienne dénomination "TrustLane"

Une nouvelle fonctionnalité fait son apparition dans le systray de l'Agent de poste : les diagnostics embarqués !

Cette fonction, à destination des administrateurs, permet (dans cette première version) de lancer une série de diagnostics propre au fonctionnement de l'Agent pour tester la connectivité de bout en bout de l'Agent au service Olfeo SaaS et permettre d'isoler les causes d'une absence d'accès à internet sur un poste où l'Agent est installé.

Au lancement d'un diagnostic l'Agent va tester la présence de fichiers clés (configuration, certificats), tester l'accessibilité interne du routeur et du proxy sur le poste, puis tester la connectivité TCP avec deux mires publiques (pour valider l'absence de portail captif ou de restrictions firewall par ex.) et enfin tester la connectivité au service Olfeo SaaS lui-même.

Des évolutions seront régulièrement apportées dans les mois qui viennent à cette fonctionnalité pour vous permettre de comprendre les problèmes d'accès à internet de vos utilisateurs protégés par Olfeo SaaS.

Retrouvez tous les détails de cet outil de diagnostics embarqués dans la documentation de l'Agent de poste (profondément remaniée d'ailleurs, si vous avez des remarques, nous sommes à votre écoute !).

La transition vers notre nouvelle identité se poursuit : l'icône de l'Agent de poste évolue pour adopter un format similaire au favicon du produit (la modification du nom du service interviendra dans une prochaine mise à jour).

L'icône du systray s'adapte au thème (sombre ou clair) de votre OS et gère à présent les statuts avec des niveaux de transparence distincts selon que l'Agent dispose de crédences pour se connecter au service distant ou non.

Une refonte en profondeur des mécanismes de résilience de l'Agent de poste a été entrepris ces derniers mois pour améliorer son comportement lorsqu'un ou plusieurs services sont inaccessibles ou lorsque des fichiers nécessaires à son fonctionnement sont indisponibles ou inexploitables.

La version de go a été mise à jour vers la 1.20.1

Dans certains cas de figures rares, le statut de connexion peut ne plus s'afficher dans l’interface du systray. Notez que cela n’a pas d’effet sur l'authentification de vos utilisateurs sur Olfeo SaaS, non plus que sur le service Windows de l’Agent lui-même.

En cas de perte de connexion avec la plateforme TrustLane, l’Agent ne supprime plus les jetons d’accès automatiquement mais retente régulièrement de se reconnecter.

Pour votre utilisateur, cela se traduit par une présentation moins fréquente de la page d’authentification de votre IDP.

Les évènements sur les groupes sont mieux gérés et se traduisent par moins de réauthentifications (apparition de la page Successful authentication).

A l’expiration des jetons d’accès, l’Agent de poste retente plus intelligemment l’authentification en cas d’échec, en particulier si les requêtes émanent d’un client/application exécuté en tâche de fond.

Le systray (composant de l’Agent de poste qui permet à votre utilisateur d’interagir avec l’Agent) a été réécrit pour permettre une meilleure évolutivité à l’avenir et améliore la communication entre le service principal et le systray.

Ainsi le systray :

* il peut encore apparaître « en double », un survol du systray avec la souris permet à Windows de rafraîchir l’affichage.

Dans le cas (rare) où ce soit une requête utilisant la méthode POST qui nécessite une (ré)authentification, l’Agent redirigera proprement la requête (Redirect 303).

Lorsqu’on tente d’installer (via le msi sous Windows) une version antérieure de l’Agent à celle déjà installée, un message explicite est désormais affiché.

Diverses corrections mineures ont été apportées pour corriger quelques défauts mineurs de sécurité.

Dans certains cas de figures rares, si le systray est amené à redémarrer, il peut ne pas afficher de statut de connexion dans l’interface. Notez que cela n’a pas d’effet sur le service de l’Agent lui-même.

Dans certains cas de connexion à internet en passant par un portail captif, il se peut que l’Agent mette plus longtemps que prévu à se reconnecter à la plateforme. La navigation internet n’est pas interrompue mais la navigation se fait momentanément en direct sans passer par la plateforme.

Des changements portant notamment sur l'emplacement des exécutables et sur leurs modalités de communication, font que la montée de version transparente (qui est habituellement la norme) ne peut s'appliquer proprement sur cette version.

Exceptionnellement, cette version nécessite donc que vous désinstalliez la version précédente et que vous installiez ensuite cette version.

Gestion de la continuité de service

On améliore le mécanisme de détection de l’Agent pour définir si le service de filtrage distant est indisponible (bugId #OC-3060).

Si l’Agent détecte que le service est indisponible, il teste beaucoup plus fréquemment son retour en ligne pour rétablir la connexion au service de filtrage.

Connexion au service de filtrage suite à l'installation

On a amélioré le processus de connexion au service distant suite à l’installation de l’Agent (bugId #OC-3048).

Améliorations générales

La stabilité et la fiabilité générale de l’Agent ont été améliorées.

Les exécutables sont dorénavant signés avec des certificats valides.

ATTENTION : le certificat actuel est valide mais il peut déclencher des alertes de sécurité Windows.

Gestion de la continuité de Service

L’Agent utilise désormais un cache interne pour stocker la résolution DNS du meilleur endpoint d’accès à la plateforme et optimiser les requêtes DNS faites et l’empreinte réseau.

Icône du systray (Windows)

L'icône du systray s'affiche dorénavant systématiquement.