Stima dei tempi necessari per l'integrazione SSO

L’SSO consiste principalmente nelle peculiarità altrui: occorre innanzitutto configurare il provider di identità, e il resto è solo una questione di infrastruttura.

“Aggiungi SSO” sembra indicare una sola funzionalità. In realtà sono due. La prima è un piccolo aspetto tecnico relativo a OAuth, SAML o OIDC: ben documentato, esistono librerie dedicate e ogni libreria di autenticazione moderna dispone di un tutorial. La seconda è tutto ciò che il provider di identità fa e che non è presente nel tutorial: i nomi dei claim che non corrispondono alle specifiche, le regole relative agli URI di reindirizzamento più rigorose rispetto alle specifiche, il timeout della sessione che non coincide con il Vostro, l’errore di un’unità nella serializzazione dei gruppi, l’endpoint dei metadati che restituisce XML non valido ogni martedì. La prima parte è la storia su cui tutti possono esprimersi. La seconda parte è quella che conta davvero.

Il che significa che la stima non riguarda in realtà l’SSO. Riguarda questo provider di identità e il fatto che qualcuno del team abbia già effettuato un’integrazione con esso in precedenza. Okta con una configurazione SAML standard è una situazione ben diversa da Azure AD con una regola di claim personalizzata che nessuno, da entrambe le parti, comprende appieno. Un team che realizza un’integrazione con Okta in uno sprint impiegherà tre sprint per un’implementazione federata di AD FS con un proxy personalizzato a monte, e il codice che scriverà risulterà quasi identico alla fine.

Ciò che viene detto nella sala

Backend: “Si tratta di un flusso OAuth. La libreria se ne occupa. 5 punti.”

Sicurezza: “Quale IdP? Okta? Azure AD? SAML personalizzato?”

Backend: “…ha importanza?”

Sicurezza: «Sì. Le loro affermazioni non corrispondono a quelle delle specifiche.»

Domanda iniziale: “C’è qualcuno in questo team che abbia già effettuato l’integrazione con il proprio IdP?”

SRE: “Qual è la procedura di rollback nel caso in cui il sistema smetta di funzionare per metà dei nostri utenti?”

La domanda del responsabile è quella che determina la stima. Se qualcuno ha già realizzato un progetto con questo fornitore, la storia è di portata ridotta e ben definita. Se nessuno lo ha fatto, la storia consiste in due parti di lavoro dalla portata sconosciuta. La mossa giusta non consiste nel cercare di stimare con maggiore precisione, bensì nel definire un time-box per uno spike basato sul comportamento effettivo del fornitore e nel dimensionare l’implementazione in seguito.

Domande da porsi prima di votare

• Quale provider di identità, nello specifico? Okta, Azure AD, Google Workspace, Auth0, personalizzato?
• C’è qualcuno nel team che ha già effettuato un’integrazione con questo fornitore?
• OAuth, SAML o OIDC? E quale versione di ciascuno?
• Qual è il modello di gestione degli utenti: JIT, SCIM, manuale?
• Mappatura da gruppo a ruolo: è necessaria? Dove si trova tale mappatura?
• Cosa succede agli account locali esistenti durante il passaggio al nuovo sistema?
• Timeout della sessione, timeout di inattività, applicazione dell’autenticazione a più fattori (MFA): quale politica prevale?
• È possibile effettuare i test utilizzando il provider effettivo del cliente oppure solo un ambiente di prova?

Se due o più di questi elementi risultano essere «un caso a sé stante» la portata è troppo ampia: suddividete il provisioning, la mappatura dei ruoli e la migrazione in storie a sé stanti e valutate la portata del flusso di autenticazione separatamente.

Non votate un numero finché non sapete con quale provider di identità state effettuando l’integrazione. È il provider il punto cruciale.

Si veda la stima della sostituzione di un’API di terze parti per il modello correlato denominato “peculiarità di altri”, nonché gli altri esempi di stime riuscite per ulteriori approfondimenti. Avviare una sessione gratuita di planning poker una volta che lo spike abbia individuato il fornitore e le relative peculiarità.