Migrare a un altro provider IAM senza fermare l'autenticazione
Cambiare piattaforma di identità è un progetto che tocca ogni applicazione aziendale, ed è per questo che raramente si affronta di slancio. Il percorso verso LoginMaster è costruito su standard aperti — SAML 2.0, OAuth 2.0 e OpenID Connect — e procede per fasi: prima si censisce il perimetro, poi si valida in parallelo, infine si migra un'applicazione alla volta con rollback sempre disponibile.
Perché si cambia provider di identità
Le ragioni che portano un'azienda europea a rivalutare il proprio IAM si ripetono con poche varianti.
Il costo cresce con gli utenti
Il licensing per utente attivo lega la spesa IAM alla crescita dell'organizzazione: ogni nuovo dipendente, cliente o ambiente di test si traduce in costo ricorrente. LoginMaster fattura per tenant e progetto, con utenti illimitati inclusi.
Sovranità del dato
Con i provider extra-UE i dati di identità restano tecnicamente accessibili al fornitore e soggetti a normative di paesi terzi. Nell'architettura Tenant-Cloud i dati personali restano nel Tenant del cliente e il Cloud tratta solo dati cifrati e pseudonimizzati.
Consolidamenti e roadmap incerte
Acquisizioni e fusioni tra vendor IAM rimettono in discussione moduli, listini e supporto. Una piattaforma unica evita di dover riprogettare l'accesso ogni volta che il fornitore riorganizza il portfolio.
Lock-in tecnico
Regole di autorizzazione proprietarie e SDK non standard rendono costoso ogni cambio. LoginMaster si appoggia a SAML 2.0, OAuth 2.0 e OpenID Connect, con REST API e SDK TypeScript e .NET documentati.
Il processo in tre fasi
Nessun big bang: il provider esistente resta in funzione finché l'ultima applicazione non è passata.
1. Assessment della configurazione attuale
Si mappano tenant, applicazioni e policy di accesso del provider in uso, per censire ogni integrazione SSO e ogni flusso di provisioning prima che qualcosa si muova. È la fase in cui emergono le personalizzazioni proprietarie da riprogettare su standard aperti.
2. Pilota in parallelo
LoginMaster viene affiancato al provider esistente su un sottoinsieme di utenti e applicazioni. Si validano autenticazione, MFA e provisioning su casi reali senza toccare il resto dell'organizzazione, che continua a lavorare sul sistema di partenza.
3. Cutover progressivo, applicazione per applicazione
Le applicazioni migrano una alla volta, con possibilità di rollback a ogni passaggio. Non c'è un momento di switch unico: SSO e MFA restano attivi per tutta la durata della migrazione.
Cosa si migra davvero
Quattro ambiti da mettere sul tavolo prima di iniziare, ognuno con un grado di complessità diverso.
Integrazioni SSO
Le federazioni costruite su SAML 2.0, OAuth 2.0 e OpenID Connect si rimappano direttamente: gli stessi standard che il provider di partenza espone sono quelli su cui LoginMaster si integra con Google Workspace e Microsoft Entra ID.
Utenti e struttura degli accessi
Anagrafiche, progetti e ruoli si ricostruiscono nel Tenant del cliente via REST API e SDK ufficiali. Il modello multi-progetto permette di rispecchiare la segmentazione già in uso senza duplicare gli account.
Provisioning e ciclo di vita
I flussi joiner, mover e leaver si riportano su REST API, SDK e webhook. Il supporto allo standard SCIM 2.0 è previsto in roadmap di piattaforma.
Credenziali e secondo fattore
Dove l'accesso è federato via SSO la questione non si pone: l'utente continua ad autenticarsi presso il proprio identity provider aziendale. Per le credenziali gestite direttamente, la protezione con Argon2 e split-salt tra Tenant e Cloud va tenuta presente nel disegno della fase di attivazione degli utenti: è un punto da definire insieme nell'assessment.
Per il dettaglio tecnico su API, SDK e webhook usati durante il passaggio, vedi la pagina integrazione e sviluppatori e quella su provisioning e ciclo di vita utenti.
Da quale piattaforma stai migrando?
Ogni percorso ha una pagina dedicata con il confronto punto per punto e le specificità della piattaforma di partenza.
Stai valutando più opzioni europee insieme? Il confronto tra IAM europei mette a fuoco le differenze tra piattaforme ospitate in UE.
Domande frequenti sulla migrazione
L'approccio è pensato proprio per evitarlo: LoginMaster viene affiancato al provider esistente durante la fase pilota e le applicazioni passano una alla volta, con rollback disponibile a ogni passaggio. Non esiste un momento di switch unico in cui l'autenticazione si ferma per tutti.
Le pagine di confronto dedicate coprono Auth0, Okta, Keycloak, Microsoft Entra ID, AWS Cognito, Firebase Auth, Ping Identity, ForgeRock, OneLogin, JumpCloud e ZITADEL. Poiché la migrazione si appoggia a SAML 2.0, OAuth 2.0 e OpenID Connect, il percorso vale anche per provider non presenti in elenco che espongono gli stessi standard.
Dipende dal numero di applicazioni integrate, dalla quantità di policy proprietarie da riprogettare su standard aperti e dalla disponibilità dei team applicativi per il cutover. La durata realistica si definisce al termine dell'assessment, quando il perimetro è censito: chiedere una stima prima di quel punto significa lavorare su ipotesi.
I dati personali risiedono nel Tenant del cliente. Il Cloud LoginMaster opera solo su dati cifrati e riferimenti pseudonimi, quindi nemmeno il fornitore può leggere le identità dei tuoi utenti. È la differenza sostanziale rispetto a un provider che ospita le anagrafiche nel proprio cloud.
Sì, perché diversi requisiti diventano proprietà dell'architettura invece che configurazioni da mantenere: 2FA configurabile per progetto, isolamento crittografico per tenant, log integrabili nel SIEM aziendale e token a doppia firma. Il dettaglio del mapping normativo è sulla pagina dedicata alla conformità.
Partiamo dall'assessment
Il primo passo è capire cosa hai davvero in produzione: applicazioni integrate, policy di accesso, flussi di provisioning. Da lì si costruisce un piano con tempi realistici.