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 si basa su SSO via OAuth 2.0/OpenID Connect e integrazione via SDK/REST, 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 integra via SDK TypeScript/.NET e REST API documentate, con SSO a Google Workspace ed Entra ID via OAuth 2.0/OpenID Connect (SAML 2.0 in roadmap).
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
L'SSO verso Google Workspace e Microsoft Entra ID si ricrea via OAuth 2.0/OpenID Connect; le applicazioni si collegano tramite gli SDK LoginMaster e le REST API. La federazione SAML 2.0 con altri IdP è in roadmap.
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, mentre l'hub delle alternative IAM raccoglie tutti i confronti in una tabella unica.
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 ricrea l'SSO via OAuth 2.0/OpenID Connect e collega le app tramite SDK e REST API, il team LoginMaster mappa e ricrea anche configurazioni di provider non presenti in elenco.
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.
Guide approfondite
Procedure passo-passo, esempi di richieste e confronti espliciti fra le opzioni disponibili.
Migrare da Keycloak self-hosted a un IAM gestito
Cosa significa davvero 'senza perdere gli utenti', le tre strategie di migrazione a confronto, la mappa dei concetti Keycloak, il piano per fasi con rollback e il capitolo onesto sulle credenziali.
Provisioning utenti via REST API e SDK: la guida
Joiner-mover-leaver in pratica: endpoint REST, idempotenza, webhook firmati, riconciliazione periodica, account orfani e collaudo. Con esempi TypeScript, .NET e REST puri.