Un'azienda della Grande Distribuzione Organizzata aveva un obiettivo chiaro: abbattere i costi delle licenze di SAP BusinessObjects passando a una piattaforma di business intelligence open source (Apache Superset).

L'ostacolo principale era non perdere il lavoro pregresso. L'azienda aveva già investito in modo consistente nello sviluppo di query, analisi e policy di sicurezza su SAP HANA, e ricostruire tutto da zero su un nuovo sistema avrebbe richiesto tempi e costi insostenibili. Il vincolo era quindi netto: sostituire lo strumento di visualizzazione senza toccare il motore dei dati. SAP HANA resta al centro dell'architettura, ed è proprio questo il punto: ciò che andava sostituito era lo strato di BI, non il database.

Attorno a questo vincolo ruotavano tre obiettivi.

1. Abbattimento dei costi: sostituire le licenze SAP BusinessObjects con uno stack di BI interamente open source.
2. Sicurezza end-to-end: riutilizzare integralmente le regole di accesso ai dati già definite a livello di database su SAP HANA, portando l'identità dell'utente intatta dal login fino alla singola query.
3. Estensibilità: disaccoppiare l'architettura dai singoli metodi di autenticazione, predisponendola all'aggiunta di nuovi domini di identità o di nuovi database target.

Abbiamo progettato un'architettura basata su componenti open source (Apache Superset, Keycloak, Redis, PostgreSQL) che funge da ponte perfetto tra il mondo SAP e la nuova dashboard, l lavoro si è sviluppato su due fronti: il riuso del patrimonio di query esistente e la propagazione dell'identità dell'utente dal browser fino al database.

1. Il riuso del patrimonio di query
Superset è stato messo in condizione di leggere e riutilizzare le query e le logiche di calcolo sviluppate su SAP HANA per SAP BusinessObjects. L'integrazione che lo rende possibile è un componente sviluppato dal nostro team, di cui non pubblichiamo i dettagli implementativi. Il risultato per il cliente è che il patrimonio analitico costruito negli anni non è stato riscritto: nuova interfaccia, stesso motore di calcolo, zero tempi di riscrittura.

2. Sicurezza End-to-End e accesso semplificato
Abbiamo reso l'esperienza utente trasparente. L'utente accede con le proprie credenziali aziendali classiche (gestite tramite Keycloak). Dietro le quinte, la nostra architettura prende l'identità dell'utente e la "trasporta" intatta fino al database SAP HANA (Single Sign-On).
Questo significa che HANA riconosce esattamente chi sta facendo la richiesta e applica le proprie regole di visibilità dei dati. Se un utente poteva vedere solo i dati del Nord Italia in SAP BO, continuerà a vedere solo quelli in Superset, senza che gli amministratori debbano configurare nuovamente i permessi.

La piattaforma poggia su quattro componenti, tutti open source.

• Apache Superset è lo strato di business intelligence e dashboarding self-service, l'ambiente con cui gli utenti costruiscono e consultano le analisi.
• Keycloak è il sistema di Identity & Access Management centralizzato: astrae i provider di autenticazione – ad esempio Active Directory – ed è il punto unico da cui passano le identità.
• Redis gestisce la cache di sessione e fa da store temporaneo per la propagazione dei token nelle elaborazioni asincrone.
• PostgreSQL è il database dedicato ai metadati di Superset.

Implementazione tecnica

Il cuore della soluzione sta in due estensioni sviluppate su misura, che insieme portano l'identità dell'utente dal browser fino al database.

La prima è un Security Manager personalizzato, che gestisce l'autenticazione e il mapping dei claim. Estendendo il Security Manager di Flask-AppBuilder, il flusso di login viene reindirizzato su Keycloak tramite Authorization Code Flow OIDC. Al termine dell'autenticazione Keycloak restituisce a Superset l'access token dell'utente – insieme a refresh token e id token – che viene conservato nella sessione. Attraverso l'override del metodo oauth_user_info, Superset interroga l'endpoint userinfo di Keycloak e traduce automaticamente i claim OIDC standard nelle profilazioni RBAC interne alla piattaforma: chi entra si ritrova con i ruoli che gli competono, senza gestione manuale.

La seconda è un DB Connection Mutator, che propaga l'identità fino a SAP HANA. È una classe custom che riscrive dinamicamente la connessione verso il database, configurandola per autenticarsi con l'access token dell'utente. È qui che si realizza la sicurezza end-to-end: HANA riconosce il token perché Keycloak è impostato come identity provider attendibile e ne valida direttamente la firma. Il database applica quindi le proprie regole di sicurezza sull'utente nominale, esattamente quelle già in essere, senza che nulla venga replicato in Superset.

La propagazione dell'identità funziona su due binari, a seconda di come viene eseguita la query.

• Nelle richieste sincrone – le interrogazioni dirette – il mutator estrae l'access token attivo dalla sessione e stabilisce la connessione profilata su HANA. Prima di ogni richiesta il token viene rinnovato se è in scadenza, così che le sessioni di lavoro prolungate non si interrompano.
• Nelle richieste asincrone gestite dai worker Celery si presenta un limite strutturale di Superset: nel contesto di esecuzione in background l'identità dell'utente non è direttamente disponibile all'interno del mutator. Il problema è stato risolto usando Redis come canale di passaggio del token: prima di avviare il task, la sessione web salva l'access token su Redis con una scadenza breve; il worker Celery lo recupera tramite una chiave temporanea e lo passa al mutator, garantendo che anche la query in background venga eseguita su HANA con i permessi dello specifico utente. Il transito avviene su Redis protetto in TLS e con token a vita breve, così che la finestra di esposizione resti minima.

Il comportamento in caso di token scaduto è deliberatamente restrittivo: la connessione viene bloccata anziché ricadere su credenziali generiche. Meglio un errore esplicito che una query eseguita con un'identità diversa da quella dell'utente.

Un'architettura aperta ad altri database

Il meccanismo di propagazione dell'identità è indipendente dal database di destinazione: lo stesso schema si estende in linea di principio a qualsiasi motore o virtual layer, da Denodo a PostgreSQL, Oracle e SQL Server. Il metodo di autenticazione può variare da target a target – non tutti adottano il token JWT, e PostgreSQL, ad esempio, richiede un meccanismo diverso – mentre il valore pieno della soluzione, cioè l'ereditarietà della sicurezza fino al singolo utente, si esprime al meglio sui database che applicano nativamente la row-level security, come PostgreSQL, Oracle e SQL Server.

Deploy e manuetenzione

Apache Superset e Redis sono stati ingegnerizzati a container, con un sistema di deploy basato su Ansible e pipeline di CI/CD su GitLab. La scelta risponde a due esigenze concrete: rendere la soluzione adottabile anche da chi non ha un cluster Kubernetes o OpenShift in casa, e permettere di tenere aggiornati i sistemi operativi sottostanti senza impatti sulla piattaforma di BI. Lo stesso impianto consente di distribuire immagini preconfigurate con i driver necessari già a bordo, riducendo l'installazione presso il cliente alla configurazione del solo inventory.

Cosa serve per replicare lo schema

• una versione di SAP HANA che supporti l'autenticazione tramite token JWT;
• Keycloak configurato come identity provider attendibile per il database, con la firma dei token validata direttamente da HANA;
• le regole di accesso ai dati già definite sul database, che restano l'unica fonte di verità;
• un'istanza Redis raggiungibile da Superset e dai worker, protetta in TLS.

Un limite da tenere presente: poiché la sicurezza è governata sul database, ogni sorgente dati che non passi da HANA va profilata separatamente in Superset.

Abbiamo trasformato un costoso ecosistema proprietario in una piattaforma di BI self-service moderna e open source. Le regole già definite su HANA continuano a valere senza una riga riscritta, l'identità dell'utente viaggia intatta dal login fino alla query – anche quando questa è eseguita in background – e l'architettura resta aperta a nuovi database e nuovi domini di identità.

Il guadagno per l'azienda è stato triplice.

1. Economico: azzerato il canone di licenza per tutti gli utenti nominali.
2. Di sviluppo: query, logiche di calcolo e regole di sicurezza già sviluppate sono state riutilizzate senza riscritture, salvaguardando gli investimenti passati.
3. Operativo: l'utente si logga in modo trasparente e si ritrova le proprie dashboard senza interruzioni operative.
4. Infrasstrutturale: un sistema containerizzato e aggiornabile, indipendente da cluster complessi, pronto a estendersi ad altri database e ad altri scenari di deploy.