Stima dei costi di un'integrazione SSO

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

“Aggiungi SSO” sembra indicare una sola funzionalità. In realtà sono due. La prima è una piccola parte dell’infrastruttura OAuth, SAML o OIDC — ben documentata, per la quale esistono librerie 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 elemento nella serializzazione dei gruppi, l’endpoint dei metadati che restituisce XML non valido il 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 implementare un AD FS federato con un proxy personalizzato a monte — e il codice che scriverà risulterà quasi identico alla fine.

Ciò che viene detto nella stanza

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 è il piano di ripristino nel caso in cui il sistema smetta di funzionare per metà dei nostri utenti?”

È la domanda del responsabile a determinare la stima. Se qualcuno ha già effettuato una consegna utilizzando questo provider, la storia è semplice e ben definita. Se nessuno lo ha mai fatto, la storia si presenta come due parti di lavoro dalla forma sconosciuta — e la mossa giusta non è cercare di stimare con maggiore precisione, bensì definire un intervallo di tempo per uno spike basato sul comportamento effettivo del provider e dimensionare l’implementazione in un secondo momento.

Domande che vale la pena porsi prima di votare

Quale provider di identità, nello specifico? Okta, Azure AD, Google Workspace, Auth0, personalizzato?
C’è qualcuno nel team che abbia 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 o 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 separate e valutate la portata del flusso di autenticazione a sé stante.

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 terzi”, nonché gli altri esempi di stime effettuate per ulteriori approfondimenti. Avviare una sessione gratuita di Planning Poker una volta che lo spike abbia individuato il fornitore e le relative peculiarità.