Single Sign-On : comment prendre en charge toutes les applications ?
Avec une solution Enterprise Single Sign-On, l’enjeu principal est de pouvoir prendre en charge un maximum d’applications pour le processus d’authentification, mais aussi la gestion des mots de passe expirés et la délégation des identifiants.
La plupart des applications traditionnelles ouvrent leurs propres fenêtres avec un écran de connexion composé d’un champ identifiant, d’un champ mot de passe et d’un bouton de connexion. La manière dont ces éléments sont présentés peut toutefois varier fortement, ce qui peut compliquer leur prise en charge par une application SSO.
Une application SSO surveille en permanence la présence d’un écran de connexion « connu » puis exécute des étapes, par exemple renseigner l’identifiant, le mot de passe et cliquer sur un bouton. Pour garantir que l’application SSO renseigne l’identifiant dans le bon champ, il est possible d’utiliser des ID de contrôles, chaque champ ayant son propre ID pour permettre leur distinction. Il arrive toutefois que, surtout avec des applications .NET modernes, ces ID soient générés aléatoirement à chaque démarrage de l’application. Les solutions SSO avancées contournent cela en recherchant dynamiquement les ID de contrôles selon des critères tels que la position relative dans la fenêtre, le nom et la classe d’objet.
Un autre défi consiste à prendre en charge les applications web avec leurs propres écrans de connexion. Il arrive qu’une page de connexion soit constituée d’éléments de frame chargés dynamiquement, de sorte que les champs à renseigner ne se trouvent pas réellement sur la page de connexion, mais dans une page affichée via un frame. Une application SSO plus avancée peut y remédier en le détectant dans le navigateur et en apportant un support, depuis la page principale, aux champs à renseigner affichés dans des frames.
Un dernier type d’application « complexe » concerne les émulations de terminal vers des systèmes UNIX et AS/400, encore largement utilisées dans le secteur financier. Ces applications n’utilisent généralement pas de véritable boîte de dialogue ou fenêtre de connexion, mais proposent un prompt DOS ou telnet dans lequel les identifiants doivent être saisis. Dans ce cas, l’application SSO ne doit pas partir du principe qu’il s’agit d’une boîte de dialogue, mais être capable d’exécuter automatiquement une simulation de clavier, de sorte que l’application cible reçoive une séquence de frappes et réagisse comme si un « véritable » utilisateur était présent.
Dans les municipalités et dans le secteur de la santé, nous observons souvent des applications présentant les « problèmes » décrits ci-dessus, ce qui impose des exigences élevées à une application SSO. Tools4ever développe une application SSO capable de répondre à toutes ces exigences et d’offrir ainsi une solution Single Sign-On complète et robuste. Il peut être intéressant d’envisager une Proof of Concept (PoC), car il est tout à fait possible de configurer plusieurs applications pour le SSO en une journée dans un environnement pilote, afin de donner une vision claire du fonctionnement pour les utilisateurs finaux.
Cliquez ici pour plus d’informations sur le Single Sign-On (SSO).
Écrit par :
Arnout van der Vorst
Arnout van der Vorst est architecte en gestion d'identité chez Tools4ever et travaille dans l'entreprise depuis plus de 20ans. En tant qu'architecte, Arnout se concentre sur la conception et le développement de nouvelles fonctionnalités, solutions et services de la société. Arnout a étudié les sciences informatiques supérieures à la Hogeschool d'Utrecht.