Software as a Service (SaaS) è un argomento complesso con molti punti da considerare. I fornitori di software indipendenti (ISV) che creano soluzioni SaaS in Azure devono risolvere i problemi e prendere decisioni come:
- Quale modello di tenancy è necessario usare?
- Ricerca per categorie configurare una soluzione di gestione delle identità da usare in un'architettura multi-tenant?
- Ricerca per categorie gestire l'onboarding dei nuovi clienti?
Questa architettura mira a rispondere ad alcune di queste domande e a fornire un punto di partenza nel mondo del SaaS. Questa architettura è adattabile per adattarsi a un'ampia gamma di scenari.
Potenziali casi d'uso
Di seguito sono riportati alcuni casi d'uso di esempio in cui è possibile usare questa architettura:
- Modernizzare un'applicazione esistente per supportare la multi-tenancy completa come parte di un passaggio a un modello aziendale basato su SaaS.
- Sviluppare un'offerta SaaS completamente nuova.
- Eseguire la migrazione di un'offerta SaaS da un altro servizio cloud ad Azure.
Architettura
Scaricare un file PowerPoint di questa architettura.
Terminologia
Nella tabella seguente vengono descritti i termini visualizzati in questo articolo.
| Termine | Descrizione | Esempio |
|---|---|---|
| Fornitore SaaS o ISV | Entità proprietaria dell'applicazione SaaS e del codice e vende il prodotto SaaS. | Contoso Inc, vendendo la propria applicazione SaaS: Contoso Tickets. |
| Tenant | Istanza acquistata dell'applicazione SaaS dal fornitore SaaS. | Quarta caffetteria. |
| Amministratore del cliente SaaS | Persone chi acquista o amministra un tenant dell'applicazione. | Joe, proprietario di Fourth Coffee Shop. |
| Utente del cliente SaaS | Persone che usano un tenant dell'applicazione senza amministrarlo e in genere appartengono allo stesso gruppo o società dell'amministratore del cliente SaaS. | Jill, event manager presso Fourth Coffee Shop e Susan, cliente di Fourth Coffee Shop. |
| Utente finale | Un amministratore del cliente SaaS, un utente del cliente SaaS o qualsiasi altro tipo di utente introdotto. Si tratta di un termine generico per descrivere gli utenti che accedono all'applicazione. | Joe, Jill e Susan sono tutti utenti finali (dal punto di vista ISV). |
| Applicazione front-end | Qualsiasi applicazione front-end. | L'app onboarding e l'app SaaS sono entrambe applicazioni front-end. |
Workflow
L'amministratore del cliente SaaS passa al sito ospitato nell'app Onboarding &admin.
L'amministratore del cliente SaaS accede usando il flusso di lavoro di accesso dell'utente.
L'amministratore del cliente SaaS completa il flusso di onboarding.
L'amministratore del cliente SaaS passa all'area di amministrazione del tenant nell'app Onboarding &admin e aggiunge un utente del cliente SaaS al tenant appena creato.
L'utente del cliente SaaS passa all'app dell'applicazione SaaS e usa l'applicazione SaaS.
Accesso utente
Il flusso di lavoro di accesso dell'utente è costituito dai passaggi seguenti:
L'utente finale passa a un'applicazionefront-end e seleziona un pulsante Di accesso.
L'applicazione Front-end reindirizza l'utentefinale a una pagina di accesso ospitata dal provider di identità.
L'utentefinale immette le informazioni sull'account e invia il modulo di accesso al provider di identità.
Il provider diidentità invia una richiesta POST con l'indirizzo di posta elettronica e l'ID oggetto dell'utente finale per recuperare le autorizzazioni e i ruoli.
L'API Dati autorizzazione cerca le informazioni dell'utente finale nell'archiviazione dei dati delle autorizzazioni e restituisce un elenco di autorizzazioni e ruoli assegnati all'utente finale.
Il provider di identità aggiunge le autorizzazioni e i ruoli come attestazioni personalizzate al token ID, ovvero un token Web JSON (JWT).
Il provider di identità restituisce un token ID all'utentefinale e avvia un reindirizzamento all'applicazione front-end.
L'utente finale viene reindirizzato all'endpoint di accesso nell'applicazione front-end e presenta il token ID.
L'applicazione Front-end convalida il token ID presentato.
L'applicazione Front-end restituisce una pagina di accesso riuscita e l'utente finale ha eseguito l'accesso.
Per altre informazioni sul funzionamento di questo flusso di accesso, vedere Protocollo openID Connessione.
Eseguire l'onboarding di un nuovo tenant
Il flusso di lavoro di onboarding del tenant è costituito dai passaggi seguenti:
L'amministratore del cliente SaaS passa all'app Onboarding &admin e completa un modulo di iscrizione.
L'app Onboarding &admin invia una richiesta POST all'API dati tenant per creare un nuovo tenant.
L'API dati tenant crea un nuovo tenant nell'archiviazione dei dati del tenant.
L'API dati tenant invia una richiesta POST all'API dati di autorizzazione per concedere all'amministratoredel cliente SaaS le autorizzazioni per il tenant appena creato.
L'API Dati autorizzazione crea un nuovo record di autorizzazione nell'archivio dati di autorizzazione.
L'API dati di autorizzazione restituisce correttamente.
L'API dati tenant restituisce correttamente.
L'app Onboarding &admin invia una richiesta POST al provider di notifica tramite posta elettronica per inviare un messaggio di posta elettronica "tenant creato" all'amministratore del cliente SaaS.
Il provider di notifiche tramite posta elettronica invia il messaggio di posta elettronica.
Il provider di notifica tramite posta elettronica restituisce correttamente.
L'app Onboarding &admin invia una richiesta al provider di identità per aggiornare il token ID dell'amministratore del cliente SaaS in modo che includa un'attestazione JWT al tenant appena creato.
Il provider diidentità invia una richiesta POST con l'indirizzo di posta elettronica e l'ID oggetto dell'amministratore del cliente SaaS per recuperare le autorizzazioni e i ruoli.
L'API Dati autorizzazione cerca le informazioni dell'amministratore del cliente SaaS nell'archiviazionedei dati delle autorizzazioni e restituisce un elenco di autorizzazioni e ruoli assegnati all'amministratore del cliente SaaS.
Il provider di identità aggiunge le autorizzazioni e i ruoli come attestazioni personalizzate al token ID.
Il provider di identità restituisce il token ID all'app onboarding e Amministrazione.
L'app Onboarding &admin restituisce un messaggio di esito positivo e un nuovo token ID all'Amministrazione del cliente SaaS.
Aggiungere un utente a un tenant
L'aggiunta di un utente a un flusso di lavoro tenant è costituita dai passaggi seguenti:
L'amministratore del cliente SaaS richiede di visualizzare un elenco di tenant dall'area di amministrazione del tenant nell'app Onboarding &admin.
L'app Onboarding &admin invia una richiesta GET all'API dati tenant per ottenere un elenco di tenant per l'amministratore del cliente SaaS.
L'API dati tenant invia una richiesta GET all'API dati di autorizzazione per ottenere un elenco di tenant a cui l'amministratoredel cliente SaaS ha accesso per la visualizzazione.
L'API Dati autorizzazione restituisce un elenco di autorizzazioni del tenant.
L'API dati tenant cerca le informazioni del tenant nell'archiviazione dati tenant e restituisce un elenco di dati del tenant in base all'elenco delle autorizzazioni tenant ricevute.
L'app Onboarding &admin restituisce l'elenco dei dati del tenant all'amministratore del cliente SaaS.
L'amministratore del cliente SaaS seleziona un tenant dall'elenco per aggiungere un utente del cliente SaaS a e immette l'indirizzo di posta elettronica per l'utente del cliente SaaS.
L'app Onboarding &admin invia una richiesta POST all'APIdati tenant per aggiungere un'autorizzazione per l'utentedel cliente SaaS nel tenant specificato.
L'API dati del tenant verifica che l'amministratore del cliente SaaS disponga di un'attestazione JWT valida per il tenant specificato e disponga dell'autorizzazione di scrittura dell'utente.
L'API dati tenant invia una richiesta POST all'API dati di autorizzazione per aggiungere un'autorizzazione per l'utente del cliente SaaS nel tenant specificato.
L'API dati di autorizzazione invia una richiesta GET al provider di identità per cercare l'utente del cliente SaaS dall'indirizzo di posta elettronica fornito.
Il provider di identità restituisce l'ID oggetto dell'utente del cliente SaaS.
L'API Dati autorizzazione aggiunge un record di autorizzazione nell'archiviazione dei dati di autorizzazione per l'utente del cliente SaaS nel tenant specificato usando il relativo ID oggetto.
L'API dati di autorizzazione restituisce correttamente.
L'API dati tenant restituisce correttamente.
L'app Onboarding &admin viene restituita correttamente.
Componenti
Questa architettura usa i servizi di Azure seguenti:
servizio app consente di creare e ospitare app Web e app per le API nel linguaggio di programmazione scelto senza dover gestire l'infrastruttura.
Azure Active Directory B2C consente facilmente la gestione delle identità e degli accessi per le applicazioni degli utenti finali.
Database SQL di Azure, ovvero un servizio gestito di database relazionale di uso generale che supporta dati relazionali, dati spaziali, JSON e XML.
App per la logica di Azure consente di creare rapidamente integrazioni avanzate usando un semplice strumento GUI.
Alternative
L'efficacia di qualsiasi scelta alternativa dipende notevolmente dal modello di tenancy che si intende supportare per l'applicazione SaaS. Di seguito sono riportati alcuni esempi di approcci alternativi che è possibile seguire quando si implementa questa soluzione:
La soluzione corrente usa Azure Active Directory B2C come provider di identità. È invece possibile usare altri provider di identità, ad esempio Microsoft Entra ID.
Per requisiti di sicurezza e conformità più rigorosi, è possibile scegliere di implementare la rete privata per la comunicazione tra servizi.
Anziché usare chiamate REST tra servizi, è possibile implementare uno stile architetturale basato su eventi per la messaggistica tra servizi.
Considerazioni
Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che è possibile seguire per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.
Sicurezza
La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.
Questa soluzione si basa sull'identità come paradigma di sicurezza. L'autenticazione e l'autorizzazione per le app Web e le API sono regolate da Microsoft Identity Platform, responsabile del rilascio e della verifica dei token ID utente (JWT).
Ottimizzazione dei costi
L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.
I componenti di questa soluzione hanno un costo associato al loro funzionamento, ma il costo è modesto per la maggior parte delle applicazioni Web e delle soluzioni SaaS. È anche possibile controllare il costo gestendo le impostazioni delle risorse seguenti:
È possibile ridimensionare il piano di servizio app che esegue l'applicazione in base alla velocità effettiva necessaria. Inoltre, è possibile eseguire ogni app in un piano separato se è necessaria una velocità effettiva più elevata, ma si comporta un costo più elevato di conseguenza. Per altre informazioni, vedere panoramica del piano di servizio app Azure.
Azure AD B2C offre due SKU: Premium P1 e Premium P2. Entrambi gli SKU includono una quantità gratuita per il numero di utenti attivi mensili( MAU), ma è necessario valutare le funzionalità fornite da ogni SKU per determinare quale è necessario per il caso d'uso. Per altre informazioni, vedere prezzi Microsoft Entra per ID esterno.
Azure SQL offre diversi modelli di acquisto per adattarsi a un'ampia gamma di casi d'uso, inclusa la possibilità di ridimensionare automaticamente. È necessario valutare l'utilizzo nei propri database per assicurarsi che le dimensioni siano corrette. Per altre informazioni, vedere Confrontare modelli di acquisto basati su vCore e DTU di database SQL di Azure.
Efficienza prestazionale
L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica del pilastro dell'efficienza delle prestazioni.
Questa architettura deve essere in grado di soddisfare facilmente la maggior parte dei carichi di lavoro medio-grandi. Poiché l'architettura usa principalmente i servizi PaaS (Platform) di Azure, sono disponibili molte opzioni per regolare la scalabilità della soluzione in base ai requisiti e al carico.
Distribuire lo scenario
Per distribuire questo scenario, vedere Azure SaaS Dev Kit in GitHub. Si tratta di un'implementazione di riferimento distribuibile di questa architettura.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Landon Pierce | Customer Engineer
Altri contributori:
- Chris Ayers | Senior Customer Engineer
- John Downs | Senior Customer Engineer
- LaBrina Loving | Principal SVC Engineering Manager
- Gary Moore | Programmatore/writer
- Nick Pinheiro | Consulente senior
- William Salazar | Senior Customer Engineer
- Ali Sanjabi | Senior Customer Engineer
- Arsen Vladimirintune | Principal Customer Engineer
- Jason Young | Principal SVC Engineering Manager
Passaggi successivi
Ecco alcune risorse aggiuntive consigliate per la creazione di un'applicazione SaaS in Azure:
- Progettare soluzioni multi-tenant in Azure : descrive le procedure consigliate.
- Considerazioni ISV per le zone di destinazione di Azure
- Microsoft Azure Well-Architected Framework
- Applicazione SaaS Wing Suggerimenti Tickets: fornisce informazioni dettagliate sui compromessi tra vari modelli di tenancy all'interno del livello del database.
Risorse correlate
- Modelli di tenancy da considerare per una soluzione multi-tenant
- Approcci architetturali per il calcolo in soluzioni multi-tenant
- Approcci architetturali per l'archiviazione e i dati in soluzioni multi-tenant
- Considerazioni su Servizio app di Azure e Funzioni di Azure per la multi-tenancy
- SaaS multi-tenant in Azure
- Modelli di progettazione cloud