Passa ai contenuti principali

Multitenant


Multitenant





Definizione


Un tenant è un gruppo omogeneo di utenti di una applicazione. In ambito SaaS un tenant è un "abbonato" al servizio che si fornisce o un cliente della applicazione.

Con multi-tenant si intende una architettura che consente a più tenant di utilizzare la stessa istanza fisica ma mantenendo una separazione delle istanze logiche della stessa applicazione.

Abbiamo la nostra applicazione distribuita in cloud e gli utenti:



Ognuno potrà vedere solo i suoi dati. La stessa cosa se gli utenti sono raggruppati in organizzazioni: ognuno potrà vedere solo i dati della propria organizzazione:


Architettura

Dal punto di vista tecnico deve succedere che la stessa istanza dell'applicazione deve gestire le utenze mantenendo una separazione logica degli utenti e una separazione fisica dei dati per implementare il massimo livello di separazione fra i tenant: un database per tenant. 



Quindi anche se i tenant condividono le stesse risorse che possono essere la VM o i dischi per i dati, conservano una separazione logica.

Soluzione proposta

Vediamo una applicazione multitenant dal punto di vista della gestione degli utenti e del flusso del processo di gestione di un sistema multitenant.
In una applicazione multitenant gli utenti vanno gestiti nel contesto dello specifico tenant di appartenenza.
Le fasi di autenticazione e autorizzazione devono essere gestiti nello specifico tenant.

Prerequisiti


Chiariamo due prerequisiti di base con l’obiettivo di ottenere una separazione forte fra i dati dei vari tenant.

Autenticazione

- Gli utenti accedono tutti dallo stesso endpoint.
- Gli utenti accedono specificando le loro credenziali e l'organizzazione di appartenenza (pippo@azienda1.it).
- Gli utenti della stessa organizzazione fanno parte dello stesso tenant
- Quando un utente fa l'accesso l'applicazione conosce a quale tenant questo appartiene.


Autorizzazione

- Quando si autorizza l'utente ad una operazione (visualizzare i record di una tabella) l'app deve tenere in considerazione il tenant dell'utente.
- I ruoli utente come "Amministratore" o "Utente" devono essere gestiti dal cliente e non dal fornitore del SaaS.
- I ruoli devono essere consistenti nel tenant di appartenenza dell'utente, al di fuori di questo non devono esistere.

Le richieste, all’interno dell’intero ecosistema applicativo, devono seguire il seguente flusso:
-          Accettare la connessione in arrivo  e autenticare l’utente se necessario
-          Intercettare le richieste e identificare il tenant di appartenenza dell’utente che ha fatto la richiesta
-          Stabilire una connessione con lo schema o il database collelato al tenant.

L’identificazione del tenant di apparteneza è ottenuto mediante l’uso di uno schema di default che contiene l’informazione che lega l’utente al tenant. Un utente può essere autenticato da un servizio esterno che passa le informazioni sul tenant usando l’http header.
Per fare questo si può definire un header http personalizzato “X-TenantID” che identifica il tenant di appartenenza.

Identificare il tenant

Dobbiamo determinare a quale tenant si riferiscono le richieste. Usando Spring Interceptor per intercettare le richieste http e prendere dall’header l’informazione sul tenant. Il tenantID così ricavato viene conservato in una variabile ThreadLocal che viene svuotata dopo il completamento della richiesta.
L’interceptor ottiene il valore dell’header http “X-TenantID” per ogni richiesta e setta il tenant corrente nella classe “TenantContext”. Se non c’è l’header sul tenant viene restituito un errore.

Connessione al database

Una volta che si è identificato il tenant di appartenenza della request bisogna reindirizzare questa su una specifica connessione di database.
Viene usata una tabella “DataSourceConfig” nello schema pubblico per contenere il legame fra tenant e connessione al database di competenza.


Licenza Creative Commons
Quest'opera è distribuita con Licenza Creative Commons Attribuzione 4.0 Internazionale (CC BY 4.0) - Condividi allo stesso modo

Commenti

Post popolari in questo blog

Alzatapparella con Shelly 2 e Alexa

Alzatapparella con Shelly 2 e Alexa

Qui spiego tutti i passaggi per installare lo Shelly 2 per automatizzare una tapparella e come configurarlo in Alexa.

Impianto attuale




Collegamenti da effettuare:

Schema teorico:





Collegamenti reali:



Impostazioni:

Dopo aver collegato tutto si procede alla configurazione.
Prima di tutto installare la App "Shelly" cercandola nel proprio store e create un account:

















JHipster - Microservizi 1

Microservizi - 1

Introduzione
In questo post descrivo come creare una architettura a microservizi con JHipster. ArchitetturaMicroservizio
Il microservizio che andremo a creare deve avere totale autonomia ed essere auto-consistente. Questo dice la letteratura. In effetti il microservizio deve svolgere un servizio "completo" a livello di modulo di business logic. Ad esempio in un sistema complesso la gestione delle mail integrata. Quindi deve fornire servizi come l'elenco delle mail di uno specifico utente, crearne, cancellarne, inviarne di nuove. Per fare questo userà il database per accedere alla lista della mail dello specifico utente (che qui ipotizziamo stiano su un db). Questo quello che deve fare. Quello che NON deve fare è autenticare l'utente che gli invia le richieste. Quindi di questa fase se ne occuperà un altro modulo. L'autenticazione, in questo prototipo, avverrà mediante token JWT. Creaiamo il microservizio.
Creato con il wizard di JHipster selezionando il…

Docker

Introduzione a Docker Cosa èDocker è un sistema di "containerizzazione" che punta a costruire uno stack tecnologico virtuale per far girare le applicazioni allo stesso modo in qualunque contesto di delivery. La virtualizzazione avviene a livello di kernel di sistema operativo quindi risulta molto più leggero un docker rispetto ad una macchina virtuale: virtualizza solo ciò che è necessario al funzionamento dello stack anziché virtualizzare l'intero sistema operativo. Con stack tecnologico intendo l'insieme di applicazioni server, librerie e componenti software in generale necessarie a far funzionare una certa applicazione.


Docker è stato sviluppato per semplificare il delivery di applicazioni complesse e supporta le architetture a microservizi.

Docker si presenta come un demone che va installato sulle macchine che devono far girare i "docker". Esistono dei meccanismo di bilanciamento per garantire l'affidabilità e la continuità del servizio oltre a gestire …