SSO et départs : évaluer un fournisseur au-delà de la connexion

Une liste de contrôle du retrait des accès SSO vérifie ce qui se passe après la suppression des accès d’une personne chez le fournisseur d’identité. Testez les nouvelles connexions, les sessions existantes, les jetons API, les assistants connectés et les membres invités manuellement. Notez quand l’accès à l’espace de travail cesse réellement, quelles exceptions subsistent et qui peut intervenir si la synchronisation de l’annuaire échoue.

La démonstration du fournisseur comprend probablement une connexion réussie. Demandez aussi une démonstration de départ. Pour un logiciel de suivi des candidatures qui contient des dossiers de candidats, des notes d’entretien et des échanges internes confidentiels, ces deux résultats comptent dans la décision d’achat.

Pourquoi tester le retrait des accès lors de l’évaluation du SSO ?

Une démonstration réussie d’authentification unique prouve qu’un mode de connexion fonctionne. Elle ne montre pas ce que deviennent les accès déjà ouverts lorsqu’une personne quitte l’entreprise.

Le débat actuel sur SAML donne une raison de poser la question dès maintenant. Dans son article du 21 septembre, SAML : une fractale de mauvaise conception, Matt Schwager, chercheur chez Trail of Bits, critique la complexité de SAML et recommande de s’orienter vers OpenID Connect. La discussion sur Hacker News remet ce choix de protocole au premier plan pour les équipes logicielles.

C’est une raison d’examiner la gestion des identités chez votre fournisseur. Cela ne prouve ni que tous les déploiements SAML sont compromis, ni que choisir OpenID Connect règle la question des départs. La décision d’achat dépasse le protocole utilisé à l’écran de connexion.

Imaginez qu’un recruteur quitte l’entreprise. Son compte est désactivé dans l’annuaire. Pourtant, il a encore un onglet de l’ATS ouvert, un jeton utilisé par un script de production de rapports et un assistant connecté à l’espace de recrutement. Une nouvelle connexion peut échouer alors que ces autres accès nécessitent un traitement distinct.

Prenez ce scénario comme un test à réaliser, pas comme une affirmation sur un produit donné. Demandez au fournisseur de montrer le comportement de sa configuration réelle. Associez les responsables des accès au recrutement et la personne qui recevra les alertes d’échec de synchronisation, sans confier toute l’évaluation à la seule personne qui a installé le SSO.

À l’issue de l’évaluation, conservez une courte fiche de validation : les accès testés, les résultats attendus, les résultats observés et les exceptions acceptées. Le service achats et la personne qui gérera les prochains départs disposeront d’informations plus précises que « SSO pris en charge ».

Distinguez connexion, provisionnement et accès à l’application

L’authentification, la gestion des membres et la révocation répondent à des questions différentes. Demandez comment le fournisseur les articule dans la configuration que vous comptez acheter.

OpenID Connect Core définit une couche d’authentification fondée sur OAuth 2.0 ainsi que des informations déclarées sur l’utilisateur. Ces fonctions ne définissent pas, à elles seules, toute la procédure de départ de votre entreprise.

Les recommandations de Microsoft sur la révocation des accès précisent les responsabilités de l’application. Celle-ci peut émettre son propre jeton de session et gérer ses propres autorisations. Désactiver l’identité dans Microsoft Entra ne donne pas à Entra la maîtrise directe de cette session. Les accès existants dépendent du comportement et de la configuration de l’application.

Le provisionnement mérite la même attention. SCIM, une norme d’échange d’informations de gestion des identités, comprend un attribut active. Son schéma de base laisse au fournisseur de services le soin d’en définir précisément le sens. Voir active=false dans une requête réussie ne prouve pas, en soi, que tous les moyens d’accès à l’application ont cessé de fonctionner.

La déconnexion a elle aussi un périmètre. La spécification OpenID Connect Back-Channel Logout, distincte du protocole principal, décrit la notification envoyée aux applications pour supprimer les sessions correspondantes. Sa prise en charge est facultative et elle distingue normalement les jetons de renouvellement avec accès hors ligne de ceux liés à une session. N’interprétez pas « prend en charge la déconnexion » comme « révoque tous les moyens d’accès ».

Vous n’avez pas besoin de savoir implémenter un protocole pour évaluer ces points. Demandez une explication claire de chaque ligne, puis une démonstration des accès importants. Une réponse utile précise le déclencheur, les types d’identités concernés, le délai attendu et les exceptions.

Convenez du déclencheur et du délai de retrait des accès

Un test de départ exige un événement initial défini et un périmètre d’accès clair. Sinon, acheteur et fournisseur peuvent observer la même démonstration sans s’accorder sur ce qui a réussi.

Consignez d’abord la configuration : formule du produit, fournisseur d’identité, obligation de passer par le SSO, connexion de provisionnement et mode d’ajout du membre de test. Un invité ajouté manuellement peut suivre une procédure différente de celle d’un salarié provisionné depuis l’annuaire. Testez l’organisation que vous utiliserez réellement.

Choisissez ensuite le déclencheur. Désactiver un utilisateur dans l’annuaire, retirer son affectation à une application, le retirer d’un groupe et supprimer son appartenance locale à un espace de travail sont des actions différentes. Testez celle que prévoit votre procédure de départ. Ajoutez des tests distincts si votre entreprise utilise d’autres déclencheurs.

Convenez d’un délai maximal acceptable pour chaque mode d’accès important. Il s’agit de votre critère de validation, pas d’un SLA universel du secteur. Demandez au fournisseur de distinguer ses engagements de ce qu’il se contente de planifier, et de préciser la marche à suivre en cas d’échec.

Vous pouvez, par exemple, exiger qu’une personne habilitée retire les accès directement dans l’application en urgence, sans attendre une synchronisation planifiée. Formalisez cette exigence dans une procédure, avec un responsable et les autorisations nécessaires. Ne supposez pas qu’elle existe simplement parce qu’un administrateur peut généralement modifier les utilisateurs.

Notez séparément trois instants : celui de l’action dans l’annuaire, celui de sa réception ou de son traitement par l’application, et celui du refus d’une requête protégée. Le message de réussite d’un connecteur constitue une preuve utile de transmission. Il n’apporte pas la même preuve qu’une tentative refusée de consultation d’un dossier protégé.

Enfin, définissez ce que signifie « retiré ». Perdre l’accès à l’espace de votre entreprise n’implique pas nécessairement la perte d’un espace personnel sans rapport, ni une déconnexion de tous les services du fournisseur. À l’inverse, une redirection dans le navigateur ne suffit pas si le jeton de cette personne permet encore de lire les dossiers de candidats.

Exécutez ce test de validation du retrait des accès SSO

Utilisez une identité temporaire et des données fictives dans un espace de test approuvé par le fournisseur. Vérifiez que les accès fonctionnent avant leur retrait, puis répétez les mêmes opérations sans conséquence après celui-ci.

Gardez un autre administrateur disponible pour rétablir la configuration. N’utilisez ni le compte d’un salarié en poste ni de vraies données de candidats pour la démonstration. La fiche ci-dessous est notre proposition de test, pas une certification ni un rapport de test produit par Kit.

Établissez la situation de départ

Créez un candidat fictif ou un autre dossier protégé sans données sensibles réelles. Vérifiez que le membre de test peut le consulter par chaque mode d’accès pris en charge que vous comptez évaluer. Si une opération ne fonctionnait pas avant le retrait, son échec ultérieur ne démontre rien sur la révocation.

Utilisez un navigateur distinct pour le membre et l’administrateur. Notez le rôle du membre, l’origine de son appartenance et ses éventuelles affectations à des groupes. Inventoriez les moyens d’accès créés sans copier leurs secrets dans la fiche.

Effectuez ensuite l’action de retrait convenue et notez l’heure. Laissez ouverte la session existante du navigateur. Un test effectué uniquement dans une nouvelle session de navigateur ne révélerait pas le comportement à examiner.

Répétez les opérations sur les accès concernés

Pour les clients OAuth, demandez au fournisseur de distinguer le moyen utilisé pour accéder aux ressources du jeton de renouvellement qui permet éventuellement d’en obtenir un autre. La RFC 7009 définit séparément la révocation des jetons et ses effets sur les jetons associés. La fiche de validation doit préciser les moyens d’accès effectivement testés, au lieu d’indiquer seulement « OAuth testé ».

Ne confondez pas une ancienne page avec un accès toujours actif. Du texte déjà affiché dans un onglet peut rester visible après la fin des autorisations. Demandez un nouveau contenu protégé et vérifiez si le serveur le renvoie. De même, ne vous contentez pas d’un message visuel « déconnecté » si les requêtes protégées continuent de réussir.

Conservez des preuves compréhensibles par un autre opérateur

Pour chaque mode d’accès, notez la dernière réponse autorisée observée et la première réponse refusée observée. Ces vérifications encadrent la période observée ; elles ne déterminent pas l’instant précis où l’accès a changé entre deux contrôles. Un test réussi ne démontre pas non plus le délai maximal du fournisseur dans le pire cas.

Une fiche concise peut comprendre les champs suivants :

N’insérez dans la fiche ni jetons ni contenu privé des réponses. Une personne habilitée à relire la fiche a besoin de preuves suffisantes pour comprendre le raisonnement, pas d’une nouvelle collection de secrets d’accès ou de données de candidats.

Si un test échoue, nommez l’opération qui fonctionne encore. « Le navigateur déjà connecté peut lire les nouvelles notes sur les candidats après le délai accepté » est plus utile que « Le SSO ne fonctionne pas ». Le fournisseur peut ainsi identifier précisément le contrôle d’accès à corriger.

Consignez les exceptions avant de valider le fournisseur

Les exceptions et la gestion des échecs font partie de la décision de validation. Un test réussi avec un salarié géré par l’annuaire ne couvre pas toutes les personnes, tous les moyens d’accès ni toutes les pannes.

Commencez par l’origine des appartenances. La documentation d’Okta sur la désactivation décrit les prérequis et les exceptions au déprovisionnement des applications. Elle rappelle une question concrète avant l’achat : quelles applications et quelles identités la connexion configurée gère-t-elle réellement ?

Recensez les membres invités manuellement, les collaborateurs externes, les comptes de service et les administrateurs de secours, lorsqu’ils existent. Attribuez à chacun une procédure de retrait et un responsable. Un compte de secours prévu à dessein ne doit pas devenir une exception invisible : documentez qui le maîtrise et comment son utilisation est vérifiée.

Testez explicitement les échecs et la reprise

Demandez comment un opérateur apprend que la synchronisation de l’annuaire s’est arrêtée ou a rejeté une modification. Un horodatage datant de la veille peut être plus instructif qu’un voyant vert « connecté ». Demandez au fournisseur sa méthode de simulation d’échec ou examinez des preuves documentées si aucune simulation sûre n’est possible.

Exécutez la procédure manuelle de secours et répétez les vérifications d’accès concernées. Cette procédure n’est utile que si l’opérateur désigné peut l’appliquer pendant l’indisponibilité de l’intégration habituelle. Confirmez les autorisations d’administration nécessaires et l’emplacement des instructions.

Testez également une réduction des droits liés au rôle et un retour dans l’espace de travail, comme deux scénarios distincts. Après la réduction des droits, vérifiez l’opération protégée que la personne ne devrait plus pouvoir effectuer. Après son retour, comparez ses autorisations au nouveau rôle approuvé. Ne présumez ni du rétablissement automatique des anciens droits ni d’une perte permanente de tous les accès.

Précisez le périmètre de la décision

Demandez l’explication écrite du fournisseur et conservez-la avec la configuration et les résultats observés. Distinguez une capacité du produit, un engagement contractuel et un résultat mesuré. Si une exception non résolue concerne des données sensibles de candidats, décidez s’il faut modifier la configuration, ajouter un contrôle applicable ou reporter la validation.

Refuser la prochaine requête ne suffit pas à récupérer des informations déjà copiées. Les fichiers téléchargés, les exports et les copies conservées relèvent d’un autre volet de la gestion des données. Concentrez cette évaluation sur l’arrêt des accès futurs à l’espace de travail.

La rigueur attendue pour les preuves ressemble à celle de la clôture d’un signalement de fuite d’identifiants : identifier le mode d’accès concerné et vérifier le résultat. Ici, l’objectif est un départ planifié et la validation d’un fournisseur, plutôt que la réponse à un incident.

Appliquez la même liste de contrôle à Kit

Évaluez le produit tel que vous le configurerez, avec ses limites. Soumettez Kit au même test de départ que celui demandé à un autre fournisseur.

Kit prend en charge l’authentification unique SAML et, séparément, une connexion de synchronisation avec l’annuaire Google Workspace. L’intégration interroge Google ; ce n’est pas un point d’accès SCIM générique. La tâche de synchronisation est planifiée toutes les heures et la page de l’annuaire propose Synchroniser maintenant. Une planification ne garantit pas un délai de retrait des accès : des erreurs en amont, des tâches retardées ou des protections peuvent empêcher une exécution réussie.

La connexion gère les appartenances qu’elle a provisionnées. Elle ne supprime ni le propriétaire du compte ni les membres invités manuellement. Déconnecter la synchronisation arrête les prochaines synchronisations sans supprimer les membres existants. Notez ces limites dans la fiche avant les tests. Consultez la documentation SSO et provisionnement depuis l’annuaire pour la configuration et les comportements pris en charge.

Une protection contre les suppressions massives est également prévue. Toute synchronisation qui supprimerait l’ensemble des membres gérés par l’annuaire est arrêtée, même si cet ensemble ne contient qu’une personne. La suppression de plus de la moitié des membres gérés est aussi arrêtée lorsque cet ensemble compte au moins quatre personnes. Les départs légitimes bloqués par ces protections nécessitent une vérification par un opérateur et la procédure de suppression manuelle.

Lorsque la synchronisation avec l’annuaire supprime effectivement une appartenance, Kit supprime les jetons API de cet utilisateur pour le compte, révoque ses moyens d’accès OAuth/MCP liés au compte et coupe les connexions en temps réel de cet utilisateur au compte. Le périmètre est l’espace de travail concerné. L’identité utilisateur globale de la personne n’est pas supprimée et aucune déconnexion de tous ses autres espaces n’est promise.

Pour les départs gérés manuellement, la documentation du contrôle des accès de l’équipe décrit Retirer du compte et l’examen des accès. Pour les éléments protégés dont cette personne est l’unique responsable, choisissez un successeur ou décidez explicitement de les laisser sans responsable avant le retrait. Le propriétaire reste protégé contre la suppression ; le SSO obligatoire conserve aussi une exception d’accès de secours pour lui. Examinez cette exception avec les paramètres de sécurité de connexion.

Ces comportements sont documentés et ont été vérifiés dans le code source. Cet article ne prétend pas avoir réalisé un test de validation réel de votre déploiement. Votre évaluation doit toujours couvrir les lignes applicables, y compris les membres ajoutés manuellement et les échecs de synchronisation.

Une décision SSO solide s’appuie sur une procédure de retrait démontrée, des délais consignés et un opérateur capable de gérer les exceptions. Utilisez cette fiche pendant un essai de Kit ou votre prochaine évaluation d’un fournisseur, et testez le départ aussi soigneusement que la connexion.