Estimation d'une intégration SSO

L’authentification unique (SSO) repose principalement sur les particularités de tiers : il suffit de configurer le fournisseur d’identité en premier lieu, le reste n’est qu’une question d’infrastructure.

« Ajouter l’authentification unique (SSO) » donne l’impression de ne concerner qu’une seule fonctionnalité. Il s’agit en réalité de deux éléments distincts. Le premier est un petit aspect technique lié à OAuth, SAML ou OIDC : il est bien documenté, des bibliothèques existent, et chaque bibliothèque d’authentification moderne propose un tutoriel. Le second englobe tout ce que fait le fournisseur d’identité et qui ne figure pas dans le tutoriel : les noms de revendications qui ne correspondent pas à la spécification, les règles relatives aux URI de redirection plus strictes que celles de la spécification, le délai d’expiration de la session qui ne correspond pas au vôtre, l’erreur de sérialisation des groupes, le point de terminaison des métadonnées qui renvoie du XML invalide le mardi. La première partie, c’est l’histoire sur laquelle tout le monde peut se prononcer. La deuxième partie, ce sont les points.

Ce qui signifie que l’estimation ne porte pas vraiment sur le SSO. Elle concerne ce fournisseur d’identité précis, et vise à déterminer si un membre de l’équipe a déjà procédé à une intégration avec celui-ci. Okta, avec une configuration SAML standard, est un cas bien différent d’Azure AD, avec une règle de revendications personnalisée que personne, d’un côté comme de l’autre, ne comprend pleinement. Une équipe capable de livrer une intégration Okta en un sprint mettra trois sprints à réaliser un déploiement AD FS fédéré avec un proxy personnalisé en amont, et le code qu’elle écrira sera pratiquement identique au final.

Ce qui se dit dans la salle

Backend : « Il s’agit d’un flux OAuth. La bibliothèque s’en charge. 5 points. »

Sécurité : « Quel fournisseur d’identité (IdP) ? Okta ? Azure AD ? SAML personnalisé ? »

Backend : « … est-ce que cela a de l’importance ? »

Sécurité : « Oui. Leurs affirmations ne correspondent pas à celles du cahier des charges. »

Question d’introduction : « Y a-t-il déjà eu quelqu’un dans cette équipe qui ait procédé à une intégration avec son IdP ? »

SRE : « Quelle serait la solution de secours si cela ne fonctionnait plus pour la moitié de nos utilisateurs ? »

C’est la question posée par le chef de projet qui détermine l’estimation. Si quelqu’un a déjà livré du travail pour ce prestataire, l’exigence est simple et bien délimitée. Si personne ne l’a fait, l’exigence se compose de deux tâches dont la nature est inconnue. La bonne approche ne consiste pas à estimer avec plus de précision, mais à définir un délai pour un « spike » en fonction du comportement réel du fournisseur, puis à dimensionner la mise en œuvre par la suite.

Questions qu’il convient de se poser avant de voter

• De quel fournisseur d’identité s’agit-il, précisément ? Okta, Azure AD, Google Workspace, Auth0, ou une solution personnalisée ?
• L’un des membres de l’équipe a-t-il déjà procédé à une intégration avec ce fournisseur ?
• OAuth, SAML ou OIDC ? Et quelle version de chacun ?
• Quel est le modèle de gestion des comptes utilisateurs : JIT, SCIM ou manuel ?
• Mise en correspondance entre groupes et rôles : en avons-nous besoin ? Où se trouve cette mise en correspondance ?
• Qu’advient-il des comptes locaux existants lors de la migration ?
• Délai d’expiration de la session, délai d’inactivité, application de l’authentification multifactorielle : quelle politique prévaut ?
• Pouvons-nous effectuer des tests avec le fournisseur réel du client, ou uniquement dans un environnement de test ?

Si deux ou plusieurs de ces éléments sont considérés comme « constituant un cas à part », le projet est trop vaste : séparez le provisionnement, la mise en correspondance des rôles et la migration en projets distincts, et évaluez la portée du flux d’authentification séparément.

Ne votez pas pour un numéro avant de savoir avec quel fournisseur d’identité vous vous intégrez. C’est le fournisseur qui fait toute la différence.

Consultez la section consacrée à l’estimation du remplacement d’une API tierce pour découvrir le modèle associé « les particularités d’un tiers », ainsi que d’autres exemples d’estimation réussis pour en savoir plus. Lancez une session gratuite de « planning poker » une fois que le « spike » aura déterminé le fournisseur et ses particularités.