Un personaggio raffigurato su un post-it che regge una piccola spina, di fronte a una grande scatola dall’aria preoccupata con un punto interrogativo sopra e un groviglio di cavi ai suoi piedi.

Stima dei costi di un’integrazione SSO

Come valutare un’integrazione SSO: il lavoro non risiede nel vostro codice, bensì nelle peculiarità del provider di identità. Le domande a cui rispondere prima di stabilire un importo.

L’SSO consiste principalmente nelle peculiarità di altri: 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 è una piccola parte dell’infrastruttura OAuth, SAML o OIDC: ben documentata, con librerie disponibili e tutorial presenti in ogni libreria di autenticazione moderna. La seconda è tutto ciò che il provider di identità fa e che non è incluso nel tutorial: i nomi dei claim che non corrispondono alle specifiche, le regole relative agli URI di reindirizzamento più rigide rispetto alle specifiche, il timeout della sessione che non corrisponde al 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.

Ciò 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 in grado di realizzare 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. Se ne occupa la libreria. 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à realizzato un progetto con questo fornitore, la storia è di portata ridotta e ben definita. Se nessuno lo ha mai 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 intervallo di tempo per uno spike basato sul comportamento effettivo del fornitore e nel dimensionare l’implementazione in un secondo momento.

Domande da porsi prima di votare

  • Quale provider di identità, nello specifico? Okta, Azure AD, Google Workspace, Auth0, personalizzato?
  • Qualcuno del team ha già effettuato un’integrazione con questo provider in passato?
  • OAuth, SAML o OIDC? E quale versione di ciascuno?
  • Qual è il modello di gestione degli utenti: JIT, SCIM, manuale?
  • Mappatura da gruppo a ruolo: ne abbiamo bisogno? Dove si trova tale mappatura?
  • Cosa accade 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 del progetto è eccessiva: si raccomanda di suddividere il provisioning, la mappatura dei ruoli e la migrazione in progetti distinti e di valutare separatamente la portata del flusso di autenticazione.

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

Si veda la sezione dedicata alla stima della sostituzione di un’API di terze parti per il modello correlato denominato “le peculiarità di qualcun altro”, nonché gli altri esempi di stime effettuate con successo per ulteriori approfondimenti. Si avvii una sessione gratuita di Planning Poker una volta che lo spike abbia individuato il fornitore e le relative peculiarità.