Eseguire il mapping delle richieste ai tenant in una soluzione multi-tenant

Ogni volta che arriva una richiesta all'applicazione, è necessario determinare il tenant per cui è destinata la richiesta. Quando si dispone di un'infrastruttura specifica del tenant che può anche essere ospitata in aree geografiche diverse, è necessario associare la richiesta in ingresso a un tenant. È quindi necessario inoltrare la richiesta all'infrastruttura fisica che ospita le risorse del tenant, come illustrato di seguito:

In questa pagina vengono fornite indicazioni per i decision maker tecnici sugli approcci che è possibile prendere in considerazione per eseguire il mapping delle richieste al tenant appropriato e i compromessi coinvolti negli approcci.

Approcci per identificare i tenant

Esistono diversi modi per identificare il tenant per una richiesta in ingresso.

Nomi di dominio

Se si usano nomi di dominio o sottodomini specifici del tenant, è probabile che le richieste possano essere facilmente mappate ai tenant usando l'intestazione Host o un'altra intestazione HTTP che include il nome host originale per ogni richiesta.

Si considerino tuttavia le domande seguenti:

• In che modo gli utenti conoscono il nome di dominio da usare per accedere al servizio?
• Si dispone di un punto di ingresso centrale, ad esempio una pagina di destinazione o una pagina di accesso, che tutti i tenant usano? In caso affermativo, in che modo gli utenti identificano il tenant a cui devono accedere?
• Quali altre informazioni vengono usati per verificare l'accesso al tenant, ad esempio i token di autorizzazione? I token di autorizzazione includono i nomi di dominio specifici del tenant?

Proprietà della richiesta HTTP

Se non si usano nomi di dominio specifici del tenant, potrebbe essere comunque possibile usare aspetti della richiesta HTTP per identificare il tenant per cui è richiesta una determinata richiesta. Si consideri, ad esempio, una richiesta HTTP che identifica il nome del tenant come tailwindtraders. Questo potrebbe essere comunicato usando quanto segue:

• Struttura del percorso URL, ad esempio https://app.contoso.com/tailwindtraders/.
• Stringa di query nell'URL, ad esempio https://contoso.com/app?tenant=tailwindtraders.
• Intestazione di richiesta HTTP personalizzata, ad esempio Tenant-Id: tailwindtraders.

Quando si usa questo approccio, è consigliabile considerare le domande seguenti:

• Gli utenti sapranno come accedere al servizio? Ad esempio, se si usa una stringa di query per identificare i tenant, sarà necessario indirizzare gli utenti al tenant corretto aggiungendo la stringa di query?
• È disponibile un punto di ingresso centrale, ad esempio una pagina di destinazione o una pagina di accesso, usata da tutti i tenant? In caso affermativo, in che modo gli utenti identificano il tenant a cui devono accedere?
• L'applicazione fornisce API? Ad esempio, l'applicazione Web è un'applicazione a pagina singola o un'applicazione per dispositivi mobili con un back-end API? In questo caso, potrebbe essere possibile usare un gateway API o un proxy inverso per eseguire il mapping del tenant.

Attestazioni di token

Molte applicazioni usano protocolli di autenticazione e autorizzazione basati su attestazioni, ad esempio OAuth 2.0 o SAML. Questi protocolli forniscono token di autorizzazione al client. Un token contiene un set di attestazioni, che sono informazioni sull'applicazione client o sull'utente. Le attestazioni possono essere usate per comunicare informazioni come l'indirizzo di posta elettronica di un utente. Il sistema può quindi includere l'indirizzo di posta elettronica dell'utente, cercare il mapping da utente a tenant e quindi inoltrare la richiesta alla distribuzione appropriata. In alternativa, è anche possibile includere il mapping del tenant nel sistema di identità e aggiungere un'attestazione ID tenant al token.

Se si usano attestazioni per eseguire il mapping delle richieste ai tenant, è consigliabile considerare le domande seguenti:

• Si userà un'attestazione per identificare un tenant? Quale attestazione verrà usata?
• Un utente può essere membro di più tenant? Se possibile, in che modo gli utenti selezionano i tenant con cui vogliono lavorare?
• Esiste un sistema di autenticazione e autorizzazione centrale per tutti i tenant? In caso contrario, come si garantisce che tutte le autorità di token rilascino token e attestazioni coerenti?

Chiavi API

Molte applicazioni espongono API. Questi potrebbero essere per uso interno all'interno dell'organizzazione o per l'uso esterno da parte di partner o clienti. Un metodo comune di autenticazione per le API consiste nell'usare una chiave API. Le chiavi API vengono fornite con ogni richiesta e possono essere usate per cercare il tenant.

Le chiavi API possono essere generate in diversi modi. Un approccio comune consiste nel generare un valore casuale crittograficamente e archiviarlo in una tabella di ricerca, insieme all'ID tenant. Quando viene ricevuta una richiesta, il sistema trova la chiave API nella tabella di ricerca e quindi la associa a un ID tenant. Un altro approccio consiste nel creare una stringa significativa con un ID tenant incluso e quindi firmare digitalmente la chiave usando un approccio come HMAC. Quando si elabora ogni richiesta, verificare la firma e quindi estrarre l'ID tenant.

Prendere in considerazione le domande seguenti:

• Come si generano ed emettono chiavi API?
• In che modo i client API riceveranno e archivieranno in modo sicuro la chiave API?
• È necessario che le chiavi API scadano dopo un periodo di tempo? Come si ruotano le chiavi API dei client, senza causare tempi di inattività?
• Si basa solo sulle chiavi API implementate dal cliente per offrire un livello di sicurezza adeguato per le API?

Certificati client

L'autenticazione del certificato client, talvolta denominata mTLS (Mutual TLS), viene comunemente usata per la comunicazione da servizio a servizio. I certificati client consentono di autenticare i client in modo sicuro. Analogamente ai token e alle attestazioni, i certificati client forniscono attributi che possono essere usati per determinare il tenant. Ad esempio, l'oggetto del certificato può contenere l'indirizzo di posta elettronica dell'utente, che può essere usato per cercare il tenant.

Quando si prevede di usare i certificati client per il mapping dei tenant, tenere presente quanto segue:

• In che modo si rilasciano e si rinnovano in modo sicuro i certificati client considerati attendibili dal servizio? I certificati client possono essere complessi da usare, perché richiedono un'infrastruttura speciale per gestire ed emettere certificati.
• I certificati client verranno usati solo per le richieste di accesso iniziali o collegate a tutte le richieste al servizio?
• Il processo di emissione e gestione dei certificati diventa non gestibile quando si dispone di un numero elevato di client?
• Come si implementerà il mapping tra il certificato client e il tenant?

Proxy inversi

Un proxy inverso, detto anche proxy di applicazione, può essere usato per instradare le richieste HTTP. Un proxy inverso accetta una richiesta da un endpoint in ingresso e può inoltrare la richiesta a uno di molti endpoint back-end. I proxy inversi sono utili per le applicazioni multi-tenant perché possono eseguire il mapping tra alcune informazioni sulle richieste, eseguendo l'offload dell'attività dall'infrastruttura dell'applicazione.

Molti proxy inversi possono usare le proprietà di una richiesta per prendere una decisione sul routing del tenant. Possono esaminare il nome di dominio di destinazione, il percorso URL, la stringa di query, le intestazioni HTTP e persino le attestazioni all'interno dei token.

In Azure vengono usati i proxy inversi comuni seguenti:

• Frontdoor di Azure è un servizio di bilanciamento del carico globale e un web application firewall. Usa la rete perimetrale globale Microsoft per creare applicazioni Web veloci, sicure e altamente scalabili.
• app Azure lication Gateway è un servizio di bilanciamento del carico del traffico Web gestito distribuito nella stessa area fisica del servizio back-end.
• Azure Gestione API è ottimizzato per il traffico api.
• Le tecnologie commerciali e open source (ospitate personalmente) includono nginx, Traefik e HAProxy.

Convalida delle richieste

È importante che l'applicazione convaliderà che tutte le richieste ricevute siano autorizzate per il tenant. Ad esempio, se l'applicazione usa un nome di dominio personalizzato per eseguire il mapping delle richieste al tenant, l'applicazione deve comunque verificare che ogni richiesta ricevuta dall'applicazione sia autorizzata per tale tenant. Anche se la richiesta include un nome di dominio o un altro identificatore del tenant, non significa che è consigliabile concedere automaticamente l'accesso. Quando si usa OAuth 2.0, si esegue la convalida esaminando il gruppo di destinatari e le attestazioni di ambito .

Quando si implementa la convalida delle richieste, è consigliabile considerare quanto segue:

• Come si autorizzano tutte le richieste all'applicazione? È necessario autorizzare le richieste, indipendentemente dall'approccio usato per eseguirne il mapping all'infrastruttura fisica.
• Usare framework di autenticazione e autorizzazione attendibili, ampiamente usati e ben gestiti e middleware, anziché implementare manualmente tutta la logica di convalida. Ad esempio, non compilare la logica di convalida della firma del token o le librerie di crittografia del certificato client. Usare invece le funzionalità della piattaforma dell'applicazione (o dei pacchetti attendibili noti) convalidati e testati.

Prestazioni

È probabile che la logica di mapping del tenant venga eseguita in ogni richiesta all'applicazione. Valutare la scalabilità del processo di mapping del tenant man mano che la soluzione aumenta. Ad esempio, se si esegue una query su una tabella di database come parte del mapping del tenant, il database supporterà una grande quantità di carico? Se il mapping del tenant richiede la decrittografia di un token, i requisiti di calcolo diventeranno troppo elevati nel tempo? Se il traffico è piuttosto modesto, è probabile che ciò non influisca sulle prestazioni complessive. Quando si dispone di un'applicazione su larga scala, tuttavia, il sovraccarico coinvolto in questo mapping può diventare significativo.

Affinità di sessione

Un approccio per ridurre il sovraccarico delle prestazioni della logica di mapping del tenant consiste nell'usare l'affinità di sessione. Anziché eseguire il mapping su ogni richiesta, valutare la possibilità di calcolare le informazioni solo sulla prima richiesta per ogni sessione. L'applicazione fornisce quindi un cookie di sessione al client. Il client passa di nuovo il cookie di sessione al servizio con tutte le richieste client successive all'interno di tale sessione.

Prendere in considerazione le domande seguenti:

• È possibile usare l'affinità di sessione per ridurre il sovraccarico del mapping delle richieste ai tenant?
• Quali servizi si usano per instradare le richieste alle distribuzioni fisiche per ogni tenant? Questi servizi supportano l'affinità di sessione basata su cookie?

Migrazione del tenant

I tenant spesso devono essere spostati nella nuova infrastruttura come parte del ciclo di vita del tenant. Quando un tenant viene spostato in una nuova distribuzione, gli endpoint HTTP a cui accedono potrebbero cambiare. In questo caso, considerare che il processo di mapping del tenant deve essere aggiornato. Potrebbe essere necessario considerare quanto segue:

• Se l'applicazione usa nomi di dominio per le richieste di mapping, potrebbe anche richiedere una modifica DNS al momento della migrazione. La modifica DNS potrebbe richiedere tempo per propagarsi ai client, a seconda del tempo di attività delle voci DNS nel servizio DNS.
• Se la migrazione modifica gli indirizzi di qualsiasi endpoint durante il processo di migrazione, è consigliabile reindirizzare temporaneamente le richieste per il tenant a una pagina di manutenzione che viene aggiornata automaticamente.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

• Daniel Scott-Raynsford | Partner Technology Strategist

Altri contributori:

• John Downs | Principal Software Engineer
• Paolo Salvatori | Principal Customer Engineer, FastTrack per Azure
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Informazioni sulle considerazioni relative all'uso dei nomi di dominio in un'applicazione multi-tenant.