La gestion de l’authentification chez Isogeo

De nos jours, l’authentification est un enjeu majeur dans la sécurité des systèmes d’information. Un bon système d’authentification assure non seulement la protection des données des utilisateurs, mais permet aussi leur accès restreint selon un système de statuts ou de rôles.

Ainsi, de plus en plus de sociétés investissent pour améliorer leurs systèmes d’authentification, avec l’implémentation de technologies comme le SSO (pour Single Sign-On, ou authentification unique), les authentifications à deux facteurs avec les confirmations par e-mail ou par SMS, ou encore la création de systèmes de sécurité biométriques avec par exemple la reconnaissance faciale ou digitale.

OAuth 2.0

De son côté et depuis plusieurs années, Isogeo implémente dans sa solution le protocole d’authentification OAuth 2.0. Chaque fois que vous accédez aux données des outils Isogeo, c’est par ce protocole que vous vous authentifiez.

OAuth 2.0 est un protocole d’autorisation et d’authentification standardisé que de plus en plus d’entreprises tendent à adopter. Son application la plus populaire se trouve dans les interfaces de connexion en SSO (Single Sign-On), lorsque l'on utilise par exemple son compte Google ou Facebook pour s’authentifier à un autre site.

L’objectif initial d’OAuth 2.0 est d’offrir un accès à des données utilisateurs stockées sur un serveur d’autorisation à une application cliente. Cela se fait en délivrant un jeton d’accès (ou access token) temporaire que l’on peut plus tard rafraîchir.

Pour mieux comprendre ce principe, disons que “je” tente de me connecter à LinkedIn (application cliente) en utilisant mon compte Google (serveur d’autorisation) : une fois mes identifiants Google renseignés dans l’interface de connexion (délivrance d’une autorisation utilisateur), Google envoie à LinkedIn le jeton d’accès qui lui permettra d’accéder à certaines informations que Google stocke (mon adresse e-mail, mon nom, mon âge, et peut-être plus...). Ce faisant, je n’ai jamais créé de compte LinkedIn, et LinkedIn n’a jamais eu accès à mon mot de passe Google dans le processus. C’est là tout l’intérêt d’OAuth 2.0 et du SSO : cela évite aux utilisateurs d’avoir à créer un compte sur plusieurs sites et donc de multiplier les risques de fuites de données personnelles.

Chez Isogeo, nous implémentons le protocole OAuth 2.0 dans notre API. Nous développons plusieurs produits qui se connectent selon différents processus d’authentification :

• Authorization Code Grant : ce processus est celui cité dans l’exemple précédent. Il est utilisé quand on cherche à se connecter à une plateforme en utilisant le système de compte d’une autre plateforme. Pour le mettre en place, l’application “cliente” (par exemple, LinkedIn) dispose de variables appelées “Client ID” et “Client Secret” qui doivent être partagées avec le serveur d’autorisation (les serveurs de Google). L’application cliente n’a jamais accès aux identifiants de l’utilisateur. Chez Isogeo, nous utilisons ce processus pour des produits comme le module de Scan.
• Client Credentials Grant : plus rare, ce processus n’exige à aucun moment qu’un utilisateur entre ses identifiants pour accéder à l’application. Certaines données peuvent être récupérées depuis le serveur d’autorisation, mais il est en général impossible de les modifier depuis l’application cliente. C’est un processus utile dans le cas d’applications Open Source. Nous utilisons ce processus pour les plugins QGIS et ArcGIS Pro, ou encore pour l’OpenCatalog.
• Resource Owner Password Credentials Grant : ce processus nécessite que l’application cliente et le serveur d’autorisation appartiennent à la même entité, car l’application cliente récupère au moment de l’authentification les identifiants de l’utilisateur (e-mail, mot de passe...). Dans notre cas, nous n’utilisons ce processus que pour la plateforme Isogeo.

Okta

Avec l’augmentation de la popularité du protocole OAuth 2.0, de nouvelles entreprises proposent des solutions innovantes de Single Sign-On adaptées aux besoins des entreprises. C’est le cas d’Okta, une solution de fédération d’identité utilisée par un de nos nouveaux clients.

Okta propose la mise en place d’un annuaire informatique contenant les identités virtuelles de chaque membre de l’entreprise. A travers un processus simplifié de mise en place d’applications, il permet à n’importe quel employé de se connecter à chacun de ses outils logiciels en utilisant uniquement son compte Okta, et donc un seul et unique couple identifiant/mot de passe. Combiné à un système de double authentification, Okta devient alors un redoutable outil de sécurité des données personnelles.

Avec l’arrivée d’un nouveau client, il nous a fallu mettre en place au cours des derniers mois un moyen de rendre notre solution compatible avec le système d’authentification Okta. Pour cela, la première étape importante fut de se renseigner sur Okta, son fonctionnement et les manières de mettre en place dans le code les prérequis de l’authentification.

Aujourd’hui, l’authentification fonctionne pour ce client, mais elle est encore incomplète. En effet, il est impossible d’authentifier des utilisateurs d’une autre entreprise utilisant Okta. Et, avec la popularité croissante de ce genre de solutions, il devient important pour Isogeo de permettre à n’importe lequel de nos clients d’utiliser des solutions de SSO ou de fédération d’identité s’il le souhaite. Il a donc fallu trouver une solution.

Au cours des derniers mois, nous avons été en contact avec Lyvoc, l’entreprise française de référence en accompagnement pour la mise en place d’Okta. Aux côtés de développeurs, nous avons réfléchi à une solution pour permettre l’authentification à plusieurs domaines Okta.

Le principe de cette solution repose sur l’e-mail des utilisateurs : selon le domaine d’e-mail (par exemple : @isogeo.fr ou @lyvoc.fr), l’API Isogeo pourra déterminer quel domaine Okta correspond (par exemple : isogeo.okta.com ou lyvoc.okta.com), et rediriger le navigateur de l’utilisateur vers l’interface de connexion associée. On appelle ce concept l’Identity Provider Discovery. Si l’utilisateur n’existe pas encore dans la base de données Isogeo, il est généré automatiquement à partir des claims (informations) envoyées par Okta après l’authentification.

Les étapes de cette mise en place seront les suivantes :

1. Permettre le stockage sécurisé des “Client ID”, “Client Secret”, du domaine d’e-mail et du domaine Okta,
2. Créer une solution multi-tenant redirigeant l’utilisateur vers l’interface de connexion à Okta et récupérant les claims (informations) des utilisateurs Okta,
3. Modifier l’interface de connexion actuelle de la plateforme Isogeo en y intégrant un nouvel onglet pour le SSO,
4. Automatiser la création d’un nouvel utilisateur si l’e-mail renseigné ne correspond à aucun utilisateur Isogeo.

A terme, notre objectif est de rendre Isogeo compatible avec tout type de solution de fédération d’identité. Et d’ici octobre 2021, attendez-vous sûrement à du changement sur la plateforme !