Estimation d'une intégration SSO

L’authentification unique (SSO) repose principalement sur les particularités propres à chaque système : commencez par configurer le fournisseur d’identité ; le reste n’est qu’une question d’infrastructure.

« Ajouter l’authentification unique (SSO) » peut sembler n’être 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 — bien documenté, pour lequel il existe des bibliothèques, 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 (« off-by-one »), 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 cette estimation ne porte pas vraiment sur l’authentification unique (SSO). Elle concerne ce fournisseur d’identité en particulier, 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 ça 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é en s’appuyant sur ce fournisseur, la tâche est simple et bien délimitée. Si personne ne l’a fait, la tâche se compose de deux éléments de travail dont la nature est inconnue — et 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 exactement ? Okta, Azure AD, Google Workspace, Auth0 ou une solution personnalisée ?
L’un des membres de l’équipe a-t-il déjà réalisé une intégration avec ce fournisseur ?
OAuth, SAML ou OIDC — et quelle version de chacun ?
Quel est le modèle de création de 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 ?
Expiration de la session, délai d’inactivité, application de l’authentification multifactorielle (MFA) — quelle politique prévaut ?
Pouvons-nous effectuer des tests sur l’environnement réel du fournisseur du client, ou uniquement sur un environnement de test ?

Si deux ou plusieurs de ces éléments s’avèrent constituer « un cas à part » le périmètre est trop vaste : séparez le provisionnement, la mise en correspondance des rôles et la migration en tâches distinctes, et évaluez le 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 l’estimation d’un changement d’API tierce pour découvrir le modèle associé « les particularités d’un tiers », ainsi que les autres exemples d’estimations concrètes pour en savoir plus. Lancez une session gratuite de Planning Poker une fois que le spike aura permis de déterminer le fournisseur et ses particularités.