Data Alchemy delega l'identità a LoginMaster
Data Alchemy trasforma documenti aziendali in dati strutturati con l'AI. Per l'autenticazione ha fatto una scelta netta: non costruirla. Ogni login, ogni ruolo e ogni secondo fattore passano da LoginMaster, mentre il team di prodotto resta concentrato sull'estrazione dati.
La sfida: un SaaS documentale non può improvvisare l'identità
Data Alchemy è una piattaforma di Intelligent Document Processing: acquisisce fatture, DDT e ordini, ne estrae i dati con motori AI e li riversa dentro gestionali come SAP, Zucchetti e TeamSystem. Significa che tratta, ogni giorno, i documenti più sensibili di un'azienda — quelli su cui si fondano contabilità e supply chain.
Un prodotto così affronta subito tre richieste che arrivano insieme dal primo cliente enterprise. La prima: «i miei dipendenti devono entrare con le credenziali aziendali», cioè Microsoft Entra ID o Google Workspace. La seconda: «il mio spedizioniere e il mio commercialista devono accedere anche loro, ma non hanno una licenza del mio tenant Microsoft». La terza, la più insidiosa: «i dati di un cliente non devono mai poter finire nella vista di un altro».
Rispondere costruendo l'autenticazione in casa sembra un progetto da poche settimane. Non lo è. Significa farsi carico per sempre di gestione password, reset sicuri, secondo fattore, protezione dal brute force, ciclo di vita e revoca dei token, provisioning e deprovisioning, audit degli accessi. È un prodotto dentro il prodotto: ogni mese di sviluppo speso lì è un mese non speso sull'accuratezza dell'estrazione documentale, che è l'unica cosa per cui i clienti pagano Data Alchemy.
La soluzione: l'applicazione non implementa l'autenticazione
Data Alchemy ha scelto di delegare l'intero dominio dell'identità a LoginMaster. L'applicazione non verifica credenziali, non custodisce password, non gestisce il secondo fattore: quando un utente accede, la piattaforma si rivolge al proprio progetto LoginMaster e ne riceve un token firmato, che verifica con una chiave pubblica dedicata.
Il punto architetturale è questo: Microsoft Entra ID, Google Workspace e gli account locali convivono senza che Data Alchemy scriva una riga di codice per nessuno dei tre. La federazione avviene dentro LoginMaster e resta trasparente all'applicazione. Se domani un cliente chiede un nuovo provider, non c'è una release di Data Alchemy da fare — c'è una configurazione di tenant da cambiare.
Lo stesso vale per gli utenti esterni. Un consulente, un fornitore o un revisore riceve un account LoginMaster e accede alla piattaforma senza consumare una licenza Microsoft o Google del cliente, e senza che le sue credenziali vengano affidate a un servizio terzo: restano nel tenant LoginMaster del cliente. È l'utente stesso a impostare la propria password e ad attivare il proprio secondo fattore, senza password provvisorie che girano via email.
Come funziona l'integrazione
Quattro proprietà architetturali che spiegano perché l'integrazione regge la crescita del prodotto senza doverla riscrivere.
- 1
L'identità vive fuori dall'applicazione
Data Alchemy non implementa la verifica delle credenziali: la delega al proprio progetto LoginMaster e riceve in cambio un token firmato, verificato con una chiave pubblica dedicata al progetto. La superficie di attacco legata alle password semplicemente non esiste nel codice dell'applicazione.
- 2
I provider aziendali sono una configurazione, non una release
Login con Microsoft Entra ID, con Google Workspace o con account LoginMaster locali: per l'applicazione sono la stessa cosa, perché il brokering avviene dentro LoginMaster. Per i clienti con Active Directory on-premise, la modalità di accesso è governata centralmente lato progetto LoginMaster.
- 3
I ruoli arrivano dal token
L'autorizzazione di Data Alchemy si appoggia al ruolo trasportato dal token — amministratore, amministratore di tenant, manager, utente, tecnico, utenza applicativa — e su questo costruisce il proprio controllo degli accessi. Cambiare il ruolo di una persona è un'operazione da console, non un intervento sul database dell'applicazione.
- 4
Isolamento per tenant, dati dove sono i clienti
Ogni cliente ha il proprio tenant dedicato e i propri dati isolati. Il tenant LoginMaster può risiedere nel datacenter del cliente: le credenziali degli utenti non vengono affidate né a Data Alchemy né a un servizio cloud di terze parti.
Il prodotto che ne è uscito senza distrazioni
Non avendo dovuto costruire un sistema di autenticazione, il team di Data Alchemy ha investito il proprio tempo dove il cliente lo misura: sulla qualità dell'estrazione documentale.
99,8%
accuratezza nell'estrazione dei dati
~3 sec
per documento elaborato
−60%
tempo operativo sui processi documentali
0
linee di codice di autenticazione da mantenere
Fonte dei dati: Le prime tre metriche sono dichiarate da Data Alchemy sul proprio sito ufficiale e si riferiscono alle prestazioni della sua piattaforma di Intelligent Document Processing, non a LoginMaster. L'ultima descrive la scelta architetturale oggetto di questo case study.
Prospettiva tecnica
Per il reparto IT
Nessun sistema di autenticazione da mantenere
Reset password, protezione dal brute force, rotazione e revoca dei token, secondo fattore: sono responsabilità di LoginMaster. Il team non viene svegliato di notte per un incidente sul login.
Onboarding degli utenti esterni senza ticket
L'utente viene invitato via email, imposta da sé la password e attiva il proprio 2FA. Nessuna password provvisoria da comunicare, nessun passaggio manuale dell'help desk.
Un solo punto di revoca
Quando una persona lascia l'azienda o un fornitore chiude il contratto, l'accesso si toglie dalla console del tenant e vale per tutta la piattaforma. Non serve rincorrere l'utenza applicazione per applicazione.
Audit degli accessi centralizzato
Chi è entrato, quando e con quale ruolo è una domanda a cui risponde l'identity provider, con evidenza tecnica utile in sede di verifica GDPR o NIS2.
Prospettiva economica
Per il CIO
Le licenze non seguono più gli utenti esterni
Consulenti, fornitori e revisori accedono con account LoginMaster. Non serve acquistare per ognuno una licenza Microsoft 365 o Google Workspace solo per farlo entrare in un'applicazione: il costo per utente esterno si sgancia dal costo della suite aziendale.
Il time-to-market non paga il pedaggio dell'autenticazione
Costruire identità in casa è un cantiere che non chiude mai. Delegandolo, il budget di sviluppo resta sul valore differenziante del prodotto — che per Data Alchemy è la precisione con cui legge un documento.
Sovranità del dato, non solo conformità sulla carta
Il tenant può stare nel datacenter del cliente, in Europa. Le credenziali non attraversano fornitori extra-UE e la risposta alle domande dei questionari di conformità è un fatto architetturale, non una promessa contrattuale.
Un fornitore di identità, molte applicazioni
Lo stesso identity provider che autentica Data Alchemy può autenticare le altre applicazioni del portafoglio. L'SSO smette di essere un progetto per applicazione e diventa un servizio trasversale.
Domande frequenti su questo case study
No. L'applicazione non implementa la verifica delle credenziali: la delega al proprio progetto LoginMaster e lavora con token firmati che verifica tramite una chiave pubblica dedicata. La gestione delle credenziali resta nel tenant LoginMaster.
Ricevono un account LoginMaster locale. Vengono invitati via email, impostano autonomamente la propria password e attivano il secondo fattore. Per l'applicazione sono utenti come gli altri, perché il tipo di provider è trasparente: cambia solo dove LoginMaster verifica l'identità.
No. Il brokering verso Microsoft Entra ID, Google Workspace o gli account locali avviene all'interno di LoginMaster. L'applicazione riceve sempre lo stesso token firmato, quindi aggiungere o cambiare provider è una configurazione di tenant, non una release del software.
Il ruolo dell'utente viaggia dentro il token emesso da LoginMaster e Data Alchemy costruisce su quel ruolo il proprio controllo degli accessi, distinguendo fra amministratori, amministratori di tenant, manager, utenti, tecnici e utenze applicative. Modificare il ruolo di una persona è un'operazione da console.
Ogni cliente ha un tenant dedicato con dati isolati, e il tenant LoginMaster può essere installato nel datacenter del cliente. Le credenziali degli utenti non vengono affidate né all'applicazione né a servizi cloud di terze parti extra-UE.
No. Il pattern — l'applicazione non implementa l'autenticazione, la delega a un identity provider che federa i provider aziendali e gli account locali — vale per qualsiasi SaaS multi-tenant che debba servire insieme dipendenti dei clienti e utenti esterni senza licenze.
Vuoi lo stesso SSO per la tua applicazione?
Se il tuo prodotto deve autenticare dipendenti con Entra ID o Google Workspace e insieme utenti esterni senza licenze, LoginMaster fa esattamente quello che fa per Data Alchemy. Parliamone.