Quando sento qualcuno dire che ha "modernizzato" un'applicazione, di solito significa che ha abilitato SAML o OIDC. Forse entrambi.
Sassofasemplificare l'accesso e ridurre l'attrito.Ma ecco ciò che mi preoccupa: troppe squadre si fermano lì. Implementano SSO e presumono che la parte difficile sia finita.
Perché “siamo modernizzati” non significa sempre quello che pensi
Quando le persone mi dicono che la loro app è stata modernizzata, mi chiedo cosa significhi veramente. In molti casi, significa solo che l'app ora supporta SSO. Utilizza ancora la stessa logica di sessione interna. L'autorizzazione è ancora codificata in profondità nell'app. È ancora fragile - solo con una pagina di accesso migliore.
Ciò che sta accadendo qui è più comune di quanto la maggior parte ammetta: modernizziamo la porta anteriore e lasciamo il resto della casa invariato.
E questo è un problema, perché l'identità non riguarda solo l'accesso, è quello che succede dopo.
Che cosa offre l’autenticazione moderna
I moderni protocolli auth come SAML e OIDC sono stati progettati per risolvere sfide reali – principalmente login e federazione.
E sì, SSO attraverso questi protocolli migliora la postura di sicurezza.Ma non confondere convenienza con completezza.
I protocolli sono progressi, ma non sono la linea di fine
Non mi sbagli, aggiungere il supporto per OIDC o SAML è un progresso. ottieni meno password, meno attrito e un'esperienza utente più coerente. Quello che non forniscono sono gli altri controlli critici su cui ci affidiamo con i sistemi di Web Access Management (WAM): controllo di sessione centralizzato, applicazione dell'autorizzazione, integrazione di directory e gestione delle politiche coerente.
I sistemi WAM non erano perfetti, ma ci hanno dato un livello di controllo coerente tra le applicazioni.Quando li abbiamo rimossi senza sostituirlo, abbiamo perso qualcosa di essenziale - e ho visto le conseguenze in prima persona.
L'app non è moderna se l'identità è ancora hard-coded
Ho visto app che sembrano lisce in superficie ma ancora si basano su identità fragili, specifiche per lo sviluppatore che si muovono dietro le quinte.In questi casi, l'aggiunta di SSO non affronta il rischio reale - comportamento incoerente tra app e ambienti.
Alcuni team utilizzano ancora librerie di sessioni obsolete. Altri codificano rigorosamente le regole di accesso in modi che rendono l'auditing un incubo. Il protocollo è moderno.
Dove le cose si rompono: la gestione delle sessioni
Uno dei più grandi punti ciechi di identità negli ambienti modernizzati è la gestione delle sessioni.La gente suppone che SSO si prenda cura di esso, ma non lo fa.
Con WAM, il comportamento delle sessioni – timelines, rinnovi, revocazioni – è stato gestito in un unico luogo. Si potrebbe applicare un cambiamento di politica e sapere che avrebbe effetto in tutta l'azienda. Oggi, la logica delle sessioni è incorporata all'interno di ogni singola app, dispersa in diverse lingue e framework.
Ho lavorato con team che usano Spring, Node.js, Rails – e anche all’interno di un unico framework, non c’è alcuna garanzia di coerenza.
Non essere in grado di imporre tempi di sessione coerenti è un rischio enorme se non riescono a revocare le sessioni quando succede qualcosa di sospetto.
Il costo della logica di sessione decentralizzata
Quando il patching delle raccolte di sessioni richiede settimane o mesi, o nessuno sa dove sono definiti i timelines, la sicurezza diventa reattiva nel migliore dei casi.
Questo non è teorico. ho visto le aziende lottare solo per tracciare come funziona il loro trattamento della sessione. è diventato conoscenza tribale, nascosto in profondità nel codice delle app.
Questo non è sostenibile, specialmente per le aziende che si occupano della conformità o degli obiettivi Zero Trust.
Drift di identità e autorizzazione
La stessa cosa che accade con la logica della sessione accade con l'autorizzazione.Una volta che viene spinto verso il basso nel codice dell'applicazione, diventa quasi impossibile gestire centralmente.
Le regole vengono sepolte nella logica aziendale. Le politiche si spostano. Alla fine, nessuno sa esattamente chi ha accesso a cosa - o perché. Anche le app che supportano l'autenticazione moderna possono fallire qui, perché AuthZ non fa parte del protocollo.
L’orchestra deve arrivare
A questo punto, penso sia chiaro: l’autenticazione moderna è solo un pezzo del puzzle.
I vantaggi dell’uso dell’orchestrazione includono:
- Riconquistare la possibilità di annullare immediatamente le sessioni
- Applicare le politiche di sessione e authZ in modo coerente
- Gestione delle chiavi di federazione e dei certificati da un unico luogo
- Integrazione con i segnali di rischio (come CAEP) per supportare Zero Trust
- E fare tutto senza riscrivere le app o cambiare i fornitori di identità
L’orchestrazione colma il divario tra il “supporto al protocollo moderno” e la vera modernizzazione dell’identità.
Centralizzare non vuol dire andare indietro
A volte la gente suppone che riportare il controllo dell'identità in un posto sia un passo indietro, ma non è di questo che si tratta l'orchestrazione.
Si tratta di abilitare l'agilità, di dare ai team di sicurezza la visibilità di cui hanno bisogno senza rallentare gli sviluppatori, di gestire l'identità come servizio, non come una serie di hacks specifici per le app.
Quando non si dispone di orchestramento, ogni sfida di identità diventa una soluzione unica.
Se sto parlando con un team di sicurezza, solitamente faccio una domanda come questa: “Quanto velocemente potresti revocare le sessioni di un utente?In ogni app della tua aziendaAdesso adesso?”
Se la risposta è qualcosa di meno di "istantaneamente", c'è un problema che vale la pena risolvere.
Il taglio: non fermarsi a SSO
Lo dirò chiaramente: l'autenticazione moderna è essenziale, ma è incompleta.Se ti fermi a SSO, ti manca il livello di controllo che rende tutto il resto funzionante - in modo sicuro, coerente e su scala.
Quindi sì, adottate SAML. Esci OIDC. Ma non lasciate che la casella di accesso sia la linea di fine. SSO e SAML da soli non fanno un
Se vuoi una vera sicurezza, l’orchestrazione deve essere parte del viaggio.
A proposito dell'autore
Darren Platt ha guidato i team di ingegneria di Securant Technologies, Ping Identity, Simplified, RSA e Oracle. Ora è il VP di Product Management e Engineering di Strata Identity, dove sta costruendo la prima piattaforma di orchestrazione di identità distribuita per ambienti distribuiti e contribuendo al nuovo standard di orchestrazione delle politiche, IDQL e il suo software di riferimento Hexa.
