Autenticazione moderna per applicazioni legacy: una spiegazione

Il tuo sistema ERP non sa cosa sia un'asserzione SAML. Nemmeno quello strumento interno vecchio di 15 anni che gestisce il tuo magazzino lo sa. Ma il tuo team di gestione delle identità ha appena implementato Microsoft Entra ID con accesso condizionale, autenticazione a più fattori e politiche zero trust ovunque.

È proprio questa lacuna che l'autenticazione moderna per le applicazioni legacy colma. È il livello che permette ai vecchi sistemi basati su credenziali di integrarsi con il Single Sign-On (SSO), l'autenticazione a più fattori (MFA) e l'identità centralizzata, senza che tu debba modificare una sola riga del loro codice.

Se sei tu a dover decidere come integrare un sistema ERP di 10 anni nel tuo progetto di implementazione di Entra ID, o se è finalmente giunto il momento di abbandonare le connessioni LDAP e NTLM, ecco tutto ciò che devi sapere sulla modernizzazione delle applicazioni legacy.

Perché le applicazioni legacy necessitano di un'autenticazione moderna

La maggior parte delle applicazioni legacy sono state create 10, 15 o addirittura 20 anni fa, quando l'autenticazione consisteva in un modulo di accesso e una verifica della password rispetto a un database locale o a un collegamento a una directory.

La maggior parte dei metodi di autenticazione tradizionali non è mai stata progettata per un mondo in cui l'identità deve viaggiare tra applicazioni cloud, VPN e dispositivi mobili, né per implementare nativamente moderne politiche di autenticazione a più fattori (MFA), di monitoraggio del dispositivo, di geolocalizzazione o di valutazione del rischio.

Nel frattempo, il resto della tua infrastruttura è andato avanti. Le tue applicazioni cloud risiedono dietro un provider di identità. I ​​tuoi dipendenti effettuano l'accesso una sola volta e ottengono tutto ciò di cui hanno bisogno per svolgere il proprio lavoro.

Le applicazioni legacy non hanno ricevuto l'avviso, ed è proprio questa lacuna che gli aggressori cercano per prima. Abbiamo analizzato i rischi specifici in dettaglio nella nostra analisi dei rischi dell'autenticazione legacy , che vale la pena leggere se devi preparare un caso interno.

Le tue applicazioni legacy utilizzano sottostanti l'autenticazione basata su moduli, LDAP, WIA, basata su header e Kerberos. Tuttavia, nessuno di questi metodi supporta nativamente l'autenticazione a più fattori (MFA) né valuta lo stato del dispositivo, la posizione o il rischio prima di concedere l'accesso.

Per i team addetti alla conformità, la situazione è ancora peggiore. GDPR, HIPAA, SOC 2 e PCI-DSS richiedono tutti una qualche forma di autenticazione forte e visibilità degli accessi. Un'app senza autenticazione a più fattori (MFA) e senza un sistema di registrazione centralizzato rappresenta una lacuna che il vostro revisore rileverà.

Autenticazione tradizionale vs. autenticazione moderna: quali sono le vere differenze?

L'autenticazione tradizionale prevede che sia l'applicazione stessa a verificare la tua identità. Memorizza, o interroga direttamente, le credenziali, convalida la password e avvia una sessione. Tutto avviene all'interno dell'applicazione stessa.

L'autenticazione moderna sposta questa funzione al di fuori dell'app. È lo standard attuale per la verifica dell'identità dell'utente, in cui un provider di identità (IdP) verifica l'utente, rilascia un token o un'asserzione firmata e l'app si fida semplicemente di quel token anziché controllare direttamente la password. Autenticazione e applicazione diventano due entità separate.

Questa distinzione è il motivo principale per cui le applicazioni legacy sono state storicamente escluse dai moderni sistemi di sicurezza. Le vecchie applicazioni presuppongono di gestire l'autenticazione. I modelli di sicurezza moderni non lo consentono.

La soluzione consiste in un traduttore che si interpone tra i due modelli. Ed è esattamente ciò che fa un Access Gateway, ma ne parleremo più dettagliatamente a breve.

Come si autenticano oggi le applicazioni legacy

L'autenticazione delle applicazioni legacy rientra generalmente in uno di cinque modelli. Prima di modernizzare qualsiasi sistema, è necessario individuare il modello specifico per ogni singola applicazione.

Autenticazione basata su moduli

L'applicazione genera autonomamente la propria pagina di accesso, invia nome utente e password al proprio server e li convalida rispetto a un database locale o a LDAP/Active Directory. Semplice e completamente indipendente da qualsiasi provider di identità o policy di autenticazione a più fattori (MFA) presente altrove nella tua infrastruttura.

Autenticazione LDAP

L'app si connette direttamente a un server LDAP o ad Active Directory utilizzando le credenziali inserite dall'utente. Funziona. Tuttavia, l'app ora ha un accesso diretto e costante alla directory: nessun token, nessuna scadenza, nessuna possibilità di aggiungere facilmente un secondo fattore di autenticazione.

Autenticazione integrata di Windows

WIA utilizza internamente NTLM o Kerberos, tramite SPNEGO, quindi una macchina aggiunta al dominio si autentica silenziosamente nel browser. Ottimo sulla LAN aziendale. Il problema si ripresenta non appena qualcuno si connette da remoto, utilizza un dispositivo personale o si trova completamente al di fuori del dominio.

Autenticazione basata sull'intestazione

L'applicazione non riceve mai una password. Si affida a un'intestazione HTTP, in genere qualcosa come REMOTE_USER, impostata da qualsiasi elemento si trovi davanti ad essa, di solito un proxy inverso o un modulo server web. Questo confine di fiducia è esattamente la porta che un moderno gateway di accesso varca.

Autenticazione Kerberos

Un sistema basato su ticket integrato in Active Directory. Il client richiede un ticket di concessione ticket al KDC, quindi un ticket di servizio per ogni risorsa a cui desidera accedere. Non viene trasmessa alcuna password, il che è un vantaggio. Rimane comunque strettamente legato al dominio Windows e risulta problematico per qualsiasi infrastruttura cloud o remota.

Lo stack di autenticazione moderno che contribuisce a proteggere le applicazioni legacy

Questi sono gli elementi costitutivi. E la maggior parte delle implementazioni ne combina diversi contemporaneamente.

SAML 2.0

Il Security Assertion Markup Language (SAML) è uno standard basato su XML per il passaggio di asserzioni di autenticazione da un provider di identità a un provider di servizi. È la scelta predefinita per molti sistemi SSO aziendali e la maggior parte degli strumenti di integrazione legacy lo supporta per primo, poiché molti provider di identità emettono asserzioni SAML di default.

OAuth2.0

È opportuno precisare che OAuth 2.0 è un framework di autorizzazione, non un protocollo di autenticazione. Regola l'accesso delegato, consentendo a un'applicazione di ottenere un token con ambito limitato per agire per conto di un utente nei confronti di un'API, senza mai visualizzare la password dell'utente.

OpenID Connect (OIDC)

OIDC aggiunge un livello di identità al di sopra di OAuth 2.0. Introduce l'ID token, un JWT firmato che contiene informazioni come l'email e il nome dell'utente, ed è proprio questo che autentica l'utente. Le applicazioni moderne che necessitano sia di login che di accesso alle API in genere combinano i due elementi.

Fornitori di identità (IdP)

Microsoft Entra ID, Okta, Ping Identity e Google Workspace svolgono tutti la stessa funzione principale: gestire la directory, verificare gli utenti ed emettere token o asserzioni firmati per ogni app connessa, comprese quelle legacy, una volta che è stata stabilita la connessione.

Accesso singolo (SSO)

Un unico login, una sessione sicura, accesso a tutto ciò a cui è connesso. Affinché un'applicazione legacy possa entrare in questo mondo, è necessario un meccanismo che traduca il suo login nativo nel flusso SSO, poiché l'applicazione stessa non è mai stata progettata per comunicare tramite SAML o OIDC.

Autenticazione a più fattori (AMF)

Una seconda prova di identità: qualcosa che possiedi o qualcosa che sei, oltre a qualcosa che sai. Invece di implementare l'autenticazione a più fattori (MFA) in ogni singola applicazione legacy, la si impone a livello del provider di identità o del gateway, e ogni applicazione connessa la eredita automaticamente.

Come abilitare l'autenticazione moderna per le applicazioni legacy

Passaggio 1. Valutare il metodo di autenticazione esistente

Verifica e cataloga ogni applicazione: è basata su moduli, LDAP, WIA, header-based o Kerberos? Non puoi colmare le lacune se non le hai mappate, e la mancanza anche di una sola di queste informazioni può compromettere l'implementazione in un secondo momento. La maggior parte delle applicazioni legacy rientra in poche categorie: strumenti sviluppati internamente o personalizzati, software di terze parti o commerciali, sistemi ERP, CRM come PeopleSoft, JD Edwards e qualsiasi sistema che utilizzi l'autenticazione header-based o LDAP.

Passaggio 2. Selezionare un provider di identità compatibile

Microsoft Entra ID, Okta, Ping Identity, Google Workspace o il tuo Active Directory esistente. L'obiettivo di questo passaggio è connettere il tuo IdP esistente alle applicazioni legacy, non sostituirlo.

Passaggio 3. Scegliere un approccio di integrazione dell'autenticazione

Per la maggior parte delle applicazioni web legacy, un proxy inverso, ovvero un gateway di accesso posto davanti all'applicazione, rappresenta la via più veloce. Intercetta la richiesta, gestisce l'handshake SAML o OIDC con il provider di identità e quindi fornisce all'applicazione una sessione attendibile, spesso tramite la stessa attendibilità basata sull'intestazione che l'applicazione già comprende.

Passaggio 4. Configurare l'accesso Single Sign-On

Punta il gateway o il connettore verso il provider di identità prescelto e configura la relazione di fiducia: scambio di metadati per SAML, ID client e segreto client per OIDC.

Passaggio 5. Abilita l'autenticazione a più fattori

Attiva l'autenticazione a più fattori (MFA) a livello dell'IdP o del gateway. Poiché si trova davanti all'applicazione, ogni applicazione legacy a valle erediterà automaticamente la stessa policy MFA.

Passaggio 6. Testare i flussi di autenticazione

Analizza ogni percorso di accesso: login, logout, timeout della sessione e cosa succede quando il provider di identità è temporaneamente irraggiungibile. Le applicazioni legacy spesso presentano casi limite, come comportamenti anomali relativi al timeout o durate fisse delle sessioni, che non corrispondono agli standard moderni. Pertanto, esegui i test con un gruppo pilota reale, non solo con il tuo team IT.

Passaggio 7. Implementazione in produzione

Iniziate con un gruppo pilota, monitorate i tassi di successo dell'accesso e le richieste di assistenza, quindi estendete il progetto. Mantenete attivo il percorso di accesso di fallback precedente finché il nuovo flusso non si sarà dimostrato stabile.

Sfide, migliori pratiche e scelta della soluzione più adatta

Sfide comuni

Alcuni aspetti ricorrono costantemente in quasi tutti i progetti di modernizzazione di applicazioni legacy. È bene tenerne conto prima di iniziare.

• Inventario delle app incompleto: I team modernizzano le app che conoscono, trascurando quelle che funzionano silenziosamente in background: un vecchio strumento di reporting, un portale di fornitori, uno script che utilizza un account di servizio.
• Mancata corrispondenza tra sessione e timeout: Le applicazioni legacy spesso presuppongono sessioni lunghe e ininterrotte. La durata dei token nelle applicazioni moderne è, per impostazione predefinita, più breve. Se questo non è corretto, gli utenti vengono disconnessi a metà dell'attività.
• Problemi di attendibilità relativi all'intestazione o ai cookie: Se un gateway trasmette l'identità tramite intestazione o cookie, l'applicazione legacy deve fidarsi completamente di quel gateway. Una configurazione errata, invece di eliminare un rischio di spoofing, crea una vulnerabilità.
• Resistenza dell'utenteQualsiasi modifica al comportamento di accesso, anche se positiva, suscita resistenza senza una comunicazione chiara. Una nuova richiesta di autenticazione a più fattori (MFA) in un'app vecchia di 15 anni può generare un gran numero di richieste di assistenza nella prima settimana.

Quando si valuta una soluzione per raggiungere questo obiettivo, ci sono alcuni aspetti che contano più della presentazione commerciale. Ad esempio, ecco alcuni elementi da considerare prima di scegliere la soluzione più adatta.

• Copertura del protocollo che comprende la parte legacy (LDAP, Kerberos, basata su header) insieme a SAML, OAuth e OIDC.
• "Nessuna modifica al codice" funziona per i tipi di app che utilizzi effettivamente, oppure solo per quelle più semplici.
• Compatibilità con l'IdP che già utilizzi, che si tratti di Microsoft Entra ID, Okta, Ping Identity o Google Workspace.
• Progetto pilota con 10 app e scalabilità a livello aziendale con 200 app. e facilità di implementazione, senza la necessità di cambiare strumento a metà del lavoro.

Best Practices

La lacuna di cui si parla in questo articolo è proprio ciò che la soluzione Legacy Apps SSO & MFA di miniOrange si propone di colmare, utilizzando un Access Gateway che si posiziona davanti alle tue applicazioni legacy e le collega a SSO, MFA e al tuo provider di identità esistente.

Ecco alcune best practice che tutti i fornitori più validi seguono per implementare l'autenticazione moderna nelle applicazioni legacy:

• Inizia con un gruppo pilotaNon si tratta di un'implementazione completa. Scegli un reparto o un'applicazione, testa l'autenticazione e l'autorizzazione separatamente, definisci i dettagli e poi estendi il progetto.
• Mappa ogni account di servizio e l'integrazione headless, non solo gli accessi umani. Questi aspetti vengono spesso trascurati e causano interruzioni in seguito.
• Mantenere coerenti le politiche relative all'autenticazione a più fattori. Questo vale sia per le app legacy che per quelle moderne. Gli utenti non dovrebbero riscontrare un'esperienza di sicurezza diversa a seconda dell'app a cui accedono.
• Documentare il piano di emergenza. Sapere esattamente come ripristinare la versione precedente nel caso in cui il nuovo flusso di autenticazione causi problemi nell'ambiente di produzione.

Conclusione

L'autenticazione moderna per le applicazioni legacy funziona al meglio come livello aggiuntivo da integrare a monte di ciò che già esiste, piuttosto che come progetto di sostituzione completa. Effettua una valutazione accurata, scegli un provider di identità affidabile e il resto è in gran parte una questione di sequenza.

Se desiderate un'analisi più approfondita dell'architettura, abbiamo pubblicato un articolo separato su come Access Gateway supporta la modernizzazione delle applicazioni legacy.

E se le applicazioni legacy sono solo una parte del tuo più ampio piano di implementazione dell'identità, la nostra soluzione completa IAM suite copre il resto.

DOMANDE FREQUENTI

Che cos'è l'autenticazione moderna?

L'autenticazione moderna viene gestita da un provider di identità centrale anziché dalla singola applicazione, utilizzando token o asserzioni firmati (SAML, OAuth 2.0 o OIDC) invece che dall'app stessa per verificare la password.

Le applicazioni legacy possono utilizzare l'autenticazione moderna?

Sì, la maggior parte delle applicazioni web legacy possono farlo, solitamente tramite un proxy inverso o un gateway di accesso che si interpone tra l'applicazione e l'applicazione stessa e gestisce il flusso di autenticazione moderno senza modificare il codice sorgente dell'applicazione.

Posso abilitare il Single Sign-On senza modificare il codice dell'applicazione?

Nella maggior parte dei casi, sì. Un gateway di accesso intercetta la richiesta prima dell'applicazione e le passa una sessione attendibile, generalmente tramite lo stesso meccanismo di fiducia basato sull'intestazione su cui si basano già molte applicazioni legacy.

Quali protocolli di autenticazione funzionano meglio per le applicazioni legacy?

Dipende dal tipo di protocollo già utilizzato dall'app. Le app basate su header e LDAP si integrano perfettamente con un approccio gateway, mentre le app che supportano SAML nativamente possono connettersi direttamente a un provider di identità.

È possibile aggiungere l'autenticazione a più fattori alle applicazioni legacy?

Sì. L'autenticazione a più fattori (MFA) viene applicata a livello del provider di identità o del gateway, quindi l'applicazione legacy la eredita senza alcun supporto nativo per l'MFA.