Tester un fournisseur d’identités 

Dans les architectures logicielles contemporaines, les applications ne réalisent plus les authentification elles-mêmes mais les délèguent à des serveurs spécialisés appelés fournisseurs d’identités.

Outre un renforcement majeur de la sécurité (serveurs dédiés robustes, facilité de montée en 2FA, MFA et authentification forte), cette architecture apporte des services additionnels : SSO, transmission de données personnelles et d’informations d’habilitation.

Il devient donc nécessaire de mettre en œuvre des logiciels de fournisseur d’identités, et de les tester avant de les interfacer avec les applications.

Le meilleur test de bon fonctionnement d’un fournisseur d’identités, c’est de réaliser une interface avec une application.

Encore faut-il en disposer d’une.

Le client de test ClientFedID

ClientFedID est une application dédiée au test des fournisseurs d’identités.

Elle a été développée par Aduneo, expert en identités numériques, dans le cadre du déploiement de solutions d’identités pour ses nombreux clients.

C’est un logiciel libre mis gratuitement à disposition de tous en licence Apache 2.0.

ClientFedID est compatible avec les protocoles OpenID Connect et SAML pour les authentifications et avec OAuth 2 pour la protection des API.

L’application permet de jouer sur les différents paramètres d’une cinématique tout en traçant l’ensemble des opérations pour aider à la correction des configurations en cas de dysfonctionnement.

On peut donc l’utiliser non seulement pour s’assurer du bon fonctionnement d’un fournisseur d’identités, mais aussi pour simuler le comportement d’une application posant problème.

Cas d’usage d’un test OpenID Connect

Pour illustrer notre propos, rien de tel qu’un exemple.

Nous allons installer un fournisseur d’identités, et utiliser ClientFedID pour en tester le fonctionnement.

Le fournisseur choisi pour l’exemple est la solution libre Keycloak. Evidemment les mêmes principes s’appliquent pour tous les autres logiciels.

Le test est effectué directement depuis un poste de travail Windows 10, sur lequel on installe ClientFedID et Keycloak.

Toutes les procédures ont été écrites pour un compte Windows sans droit d’administrateur local.

Pour plus de simplicité, elles exploitent au maximum l’invite de commande DOS.

Les procédures peuvent néanmoins être amendées en fonction du contexte. On peut par exemple réaliser sans problèmes les installations sur un serveur ou un poste Linux, que ce soit Keycloak ou ClientFedID.

Préparation du poste Windows

Tous les éléments nécessaires au test sont installés dans un même dossier racine. On prend dans l’exemple C:\bin, mais il est possible évidemment d’en changer.

On commence par le créer depuis l’invite de commandes DOS.

Comme Keycloak est une application Java, il faut installer ce langage si ce n’est pas déjà le cas.

Pour cela, on télécharge une version ZIP depuis la page https://learn.microsoft.com/en-us/java/openjdk/download (en sélectionnant Windows, x64 et zip).

Pour l’exemple, on prend le fichier microsoft-jdk-17.0.6-windows-x64.zip, dont on en dézippe le contenu dans C:\bin.

Ce dossier contient alors un dossier commençant par jdk (jdk-17.0.6+10 dans notre exemple).

Il faut alors ajouter Java dans le PATH. Il existe plusieurs méthodes pour cela. On le fait ici en ligne de commande :

Pour que la modification soit prise en compte, il faut fermer la fenêtre d’invite de commande et en ouvrir une nouvelle pour la suite des opérations.

On vérifie que c’est fonctionnel en testant la commande java -version.

 

Installer le fournisseur d’identités Keycloak

On installe le logiciel Keycloak sur le poste de travail pour les besoins du test. Habituellement, il s’installe plutôt sur un serveur.

On récupère la dernière version depuis la page https://github.com/keycloak/keycloak/releases. Lors de l’écriture de cet article, c’est la version 21.0.0.

On télécharge la version ZIP, que l’on dézippe dans C:\bin.

Dans notre exemple, ce dossier ressemble maintenant à ça :

On commence par générer un certificat auto-signé pour activer HTTPS:

Il est demandé de choisir un mot de passe, il faut entrer password qui est la valeur par défaut de Keycloak.

Concernant les informations demandées pour la génération du certificat, il est préférable de mettre localhost dans le nom et prénom. Pour le reste, on peut mettre ce qu’on veut.

Pour le premier démarrage de Keycloak, on initialise en variable d’environnement le compte administrateur. Lors des lancements ultérieurs, ce ne sera plus nécessaire (ni même pris en compte d’ailleurs) :

Le serveur est correctement démarré.

Le serveur est correctement démarré.

Pour pouvoir tester une cinématique OpenID Connect, on a besoin de créer un utilisateur dans Keycloak.

Pour cela, on se connecte à Keycloak par https://locahost:8443 dans un navigateur.

On clique sur « Administration Console », et on s’authentifie avec le login admin et le mot de passe qu’on avait donné pour KEYCLOAK_ADMIN_PASSWORD.

La bonne pratique veut qu’on n’utilise pas le realm master, mais qu’on s’en crée un, ce qu’on fait en cliquant sur la flèche vers le bas à côté de master en haut à gauche, et en sélectionnant Create Realm.

On lui donne un nom (aduneo par exemple) et on clique sur Create.

On crée ensuite notre utilisateur de test en cliquant sur Users dans le menu de gauche, puis on clique sur Create new user.

On lui donne au moins un username (claude.monet). Puis on lui renseigne aussi une adresse de messagerie fictive (claude@monet.fr) en indiquant que l’adresse a été vérifiée.

On clique ensuite sur l’onglet Credentials puis sur Set password pour lui affecter un mot de passe. On décoche Temporary car c’est un utilisateur de test.

On peut maintenant passer à l’installation de ClientFedID.

Installer Python sur le poste de test

ClientFedID étant écrit en Python 3, il faut commencer par l’installer. La version la plus stable est actuellement (début 2023) la 3.10. C’est aussi celle pour laquelle les packages s’installent le plus facilement.

On télécharge l’installateur depuis la page https://www.python.org/downloads/windows/ (Windows installer 64 bits) et on le lance.

Il faut alors cocher Add python.exe to PATH, et on pourra décoche Use admin privileges when installing py.exe (à moins que l’on dispose de droits administrateur et que l’on souhaite installer Python pour tous les comptes du poste Windows).

On lance l’installation par Install Now.

Installer ClientFedID

Une fois Python installé, on s’attaque à ClientFedID.

Il faut lancer une nouvelle invite de commandes DOS (Command Prompt). Keycloak s’exécute en effet dans celle que l’on avait ouverte. On laisse cette comme elle est, sinon Keycloack sera arrêté.

On crée d’abord un dossier où sera sauvegardée la configuration

On crée ensuite un environnement virtuel Python (qui sera dédié à ClientFedID et contiendra les packages nécessaires, dans la version correcte).

que l’on active

On lance finalement la commande d’installation

L’installation est terminée.

On notera que les fonctionnalités SAML ne sont pas actives. Pour qu’elles le soient, il faut installer les bibliothèques nécessaires, par

Configuration de ClientFedID et de Keycloak en OpenID Connect

On commence par configurer Keycloak.

On crée un client correspondant à ClientFedID, en cliquant sur le menu Clients à gauche puis sur le bouton Create client.

Il faut entrer le Client ID, qui est l’identifiant du client dans Keycloak. Un client, c’est une application interfacée avec le fournisseur d’identités. Ici on met : ClientFedID.

On fait Next.

On active Client authentication.

On clique sur Save.

Il reste des paramètres à configurer, mais on passe tout d’abord à la configuration de ClientFedID.

On lance l’application depuis sa fenêtre de commades DOS.

On vérifie que l’environnement virtuel env-python est bien actif, en regardant à gauche du prompt. Il doit s’afficher entre parenthèses.

On démarre l’application par la commande :

On doit avoir comme résultat

Dans un second onglet du navigateur (tout en gardant l’onglet Keycloak), on s’y connecte (https://localhost). Le navigateur affiche quelques avertissements pour s’assurer qu’on sait que l’on se connecte en local. On confirme qu’on a bien compris.

On ajoute ensuite une cinématique OpenID Connect en cliquant sur le bouton Add OIDC Client.

On lui donne un nom (name) : Test Keycloak.

Et on entre le Client ID dans le champ correspondant (dans Keycloak on avait mis ClientFedID, que l’on reprend évidemment ici).

Suite de la configuration

On va maintenant terminer la configuration de Keycloak.

Pour cela, on commence par copier la valeur du champ Redirect URI depuis l’onglet ClientFedID (normalement https://localhost/client/oidc/login/callback).

Puis, on bascule vers l’onglet Keycloak du navigateur, tout en gardant l’onglet ClientFedID ouvert.

Et on colle l’URL dans le champ Valid redirect URIs des Settings du client.

On sauvegarde.

On continue maintenant la configuration de ClientFedID et pour cela, on récupère le secret associé au Client ID. Dans Keycloak, on va dans l’onglet Credentials et on clique sur l’icône de copie en face du champ Client secret.

On colle cette valeur dans le champ Client secret de ClientFedID.

Il faut ensuite récupérer la valeur de Discovery URI dans Keycloak pour la mettre dans ClientFedID. On retourne dans l’onglet Keycloak et on clique sur Realm Settings dans le menu de gauche.

On copie le lien sous OpenID Endpoint Configuration, qui ressemble à https://locahost:8443/realms/aduneo/.well-known/openid-configuration et on le colle dans le champ Discovery URI de ClientFedID (dans l’onglet correspondant).

Pour finir, on décoche la case Verify certificates (car on a configuré Keycloak avec un certificat auto-signé qui ne sera pas vérifié).

On sauvegarde.

La configuration de Keycloak et de ClientFedID est terminée.

On est passé très vite dessus, mais on en expliquera le détail dans un prochain article.

Lancer un test 

On lance le test depuis la page d’accueil de ClientFedID, en cliquant sur le bouton Login situé sur la ligne Test Keycloak.

Une page récapitulative des différents paramètres de la requête OpenID Connect s’affiche.

On n’a rien à changer, on peut donc directement aller en bas de page et cliquer sur

Le navigateur est redirigé vers Keycloak où on s’authentifie avec l’utilisateur de test créé précédemment (claude.monet)

Le navigateur est de nouveau redirigé vers ClientFedID qui affiche une page avec en bas Authentication successful (ou un message d’erreur en cas de mauvaise configuration…).

On est donc bien authentifié. En d’autres termes, l’application demandant l’authentification (ClientFedID) a bien reçu un jeton d’identité de la part du fournisseur d’identités (Keycloak) et a procédé aux vérifications de conformité.

Les vérifications effectuées par ClientFedID

Le tableau menant à la réussite de l’authentification décrit les étapes franchies pour arriver à la confirmation que la cinématique a été correcte jusqu’à son terme.

En haut, on retrouve le code retourné par Keycloak (en application de la cinématique Authorization code).

Puis on voit que ClientFedID s’est connecté à l’API token de Keycloak pour échanger le code contre un jeton d’identité

Le jeton est décodé

 

Puis il est validé : vérification du nonce, de la date d’expiration, de l’émetteur (issuer), du destinataire (audience). Et enfin la signature.

Toutes les vérifications ayant correctement été menées, l’application peut récupérer l’identifiant de la personne connectée, dans la ligne ID Token sub :

Par défaut c’est un identifiant unique généré par Keycloak, mais il est possible de prendre à la place un autre champ de l’annuaire (habituellement un identifiant unique fonctionnel).

 

Mieux protéger les données par l’API userinfo

Le jeton d’identité peut dans certaines circonstances voyager sur internet (lors de la déconnexion par exemple).

On préfère donc qu’il ne contienne pas d’informations confidentielles et que ces dernières soient récupérées directement entre l’application et le fournisseur d’identités, au travers de l’API userinfo définie par OpenID Connect.

A titre l’illustration, on peut modifier la définition du scope email pour que l’adresse de messagerie ne soit plus présente dans le jeton, mais toujours récupérable par userinfo.

Si on relance une authentification, l’email n’apparaît bien plus dans le jeton.

Pour la récupérer, on initie une cinématique userinfo

Puis on clique sur Send request.

Ce qui nous retourne bien l’adresse de messagerie

Ce qu’on a appris

En quelques minutes, on a réussi à tester une authentification auprès de Keycloak en utilisant ClientFedID.

L’installation de Keycloak a été minimale et ne convient absolument pas à de la production.

On s’est basé sur Keycloak, mais les principes introduits ici s’appliquent bien sûr aux autres fournisseurs d’identités, avec selon les logiciels quelques variantes :

• au lieu de saisir le Client ID, il faut parfois copier une valeur générée par le fournisseur d’identités, sans possibilité de la changer
• il faut parfois configurer les scopes de l’on peut récupérer, même si on souhaite obtenir des scopes par défaut définis par OpenID Connect (profile et email dans notre cas, parmi la vingtaine de standard claims disponibles).
• certains fournisseurs d’identités ne publient pas de Discovery URI et il faut donc saisir manuellement et un par un les endpoints nécessaires aux cinématiques OpenID Connect

Toutes les configurations ont cependant été faites au plus rapide, pour obtenir une authentification fonctionnelle, en étant très léger sur les explications.

On s’attardera plus en détail sur une description de la cinématique utilisée, avec le détail des différents paramètres, dans un article à venir.

 

Auteur : Marc (Directeur technique)