Estimation d'une intégration SSO

L’authentification unique (SSO) repose principalement sur les particularités de tiers : il faut d’abord configurer le fournisseur d’identité, le reste n’étant qu’une question d’infrastructure.

« Ajouter le SSO » donne l’impression de ne concerner qu’une seule fonctionnalité. Il en existe pourtant deux. La première est un petit élément de l’infrastructure OAuth, SAML ou OIDC : bien documentée, elle dispose de bibliothèques, et chaque bibliothèque d’authentification moderne propose un tutoriel. La seconde 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 due à un décalage d’une unité, le point de terminaison des métadonnées qui renvoie un XML invalide les mardis. 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à effectué 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 est la procédure de retour en arrière si cela ne fonctionne 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é un projet avec ce prestataire, 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 dont la nature est inconnue. La bonne approche ne consiste pas à s’efforcer davantage d’estimer, mais à définir un délai pour un « spike » en fonction du comportement réel du fournisseur, puis à évaluer l’ampleur de 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 création de comptes utilisateurs : JIT, SCIM, manuel ?
• Mappage « groupe-rôle » : en avons-nous besoin ? Où se trouve ce mappage ?
• Qu’advient-il des comptes locaux existants lors de la migration ?
• 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 s’avèrent constituer « un cas à part » le scope est trop vaste : séparez le provisionnement, la mise en correspondance des rôles et la migration en stories 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 « Estimation d’un changement d’API tierce » pour le modèle associé « les particularités d’un tiers », ainsi que les autres exemples d’estimation concrets pour en savoir plus. Lancez une session gratuite de Planning Poker une fois que le spike aura permis de déterminer quel fournisseur choisir et quelles sont ses particularités.