Estimación de una integración de SSO

El SSO consiste, en su mayor parte, en las peculiaridades de terceros: lo primero es configurar el proveedor de identidad; el resto son cuestiones técnicas.

«Añadir SSO» parece una sola función, pero son dos. La primera es una pequeña parte de la infraestructura de OAuth, SAML u OIDC —bien documentada, con bibliotecas disponibles; todas las bibliotecas de autenticación modernas cuentan con un tutorial—. La segunda es todo lo que hace el proveedor de identidad y que no aparece en el tutorial: los nombres de las reclamaciones que no se ajustan a la especificación, las reglas de redireccionamiento URI que son más estrictas que las de la especificación, el tiempo de espera de la sesión que no coincide con el suyo, el error de «off-by-one» en la forma en que se serializan los grupos, el punto final de metadatos que devuelve XML no válido los martes. La primera parte es la historia sobre la que todo el mundo puede opinar. La segunda parte son los puntos.

Lo cual significa que la estimación no se refiere realmente al SSO. Se refiere a este proveedor de identidad y a si alguien del equipo lo ha integrado anteriormente. Okta con una configuración SAML estándar es un caso distinto al de Azure AD con una regla de reclamaciones personalizada que nadie de ninguna de las dos partes comprende del todo. Un equipo que lance una integración con Okta en un sprint dedicará tres sprints a una implementación federada de AD FS con un proxy personalizado delante, y el código que escriban resultará prácticamente idéntico al final.

Lo que se dice en la sala

Backend: «Se trata de un flujo OAuth. La biblioteca se encarga de gestionarlo. 5 puntos».

Seguridad: «¿Qué proveedor de identidades (IdP)? ¿Okta? ¿Azure AD? ¿SAML personalizado?»

Backend: «… ¿tiene importancia?»

Seguridad: «Sí. Sus afirmaciones no coinciden con las de la especificación».

Pregunta inicial: «¿Alguien de este equipo ha realizado alguna vez una integración con su IdP?»

SRE: «¿Cuál sería la solución de reversión si el sistema dejara de funcionar para la mitad de nuestros usuarios?»

La pregunta del responsable del proyecto es la que determina la estimación. Si alguien ya ha realizado entregas con este proveedor, la tarea es sencilla y está bien delimitada. Si nadie lo ha hecho, la tarea consta de dos partes de trabajo de naturaleza desconocida, y lo más acertado no es esforzarse más en la estimación, sino establecer un plazo para realizar una prueba rápida (spike) basada en el comportamiento real del proveedor y, a continuación, determinar el alcance de la implementación.

Preguntas que conviene plantearse antes de votar

¿Qué proveedor de identidad, concretamente? ¿Okta, Azure AD, Google Workspace, Auth0 o uno personalizado?
¿Hay alguien en el equipo que haya realizado una integración con este proveedor anteriormente?
¿OAuth, SAML u OIDC? ¿Y qué versión de cada uno?
¿Cuál es el modelo de gestión de usuarios: JIT, SCIM o manual?
Asignación de grupos a roles: ¿es necesaria? ¿Dónde se encuentra dicha asignación?
¿Qué ocurre con las cuentas locales existentes durante la transición?
Tiempo de espera de la sesión, tiempo de espera por inactividad, aplicación de la autenticación multifactorial (MFA): ¿qué política prevalece?
¿Podemos realizar pruebas con el proveedor real del cliente o solo en un entorno de pruebas?

Si dos o más de estos elementos se consideran «un caso aparte» la tarea es demasiado amplia: separe el aprovisionamiento, la asignación de roles y la migración en tareas independientes y evalúe el flujo de autenticación por separado.

No vote por un número hasta que sepa con qué proveedor de identidad va a realizar la integración. El proveedor es lo importante.

Consulte cómo estimar el cambio a una API de terceros para conocer el patrón relacionado «peculiaridades de terceros», y los demás ejemplos prácticos de estimación para obtener más información. Inicie una sesión gratuita de Planning Poker una vez que el «spike» haya determinado qué proveedor se va a utilizar y cuáles son sus peculiaridades.