Condividi tramite

App Web iniziale per lo sviluppo SaaS

Servizio app di Azure
Microsoft Entra per ID esterno
Database SQL di Microsoft Azure
App per la logica di azure
Azure Resource Manager

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

Diagramma dell'architettura che mostra il piano di controllo, il framework di gestione delle identità e l'utente finale S un'applicazione S.

Scaricare un file di 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.
Inquilino Istanza acquistata dell'applicazione SaaS dal fornitore SaaS. Quarta caffetteria.
Amministratore del cliente SaaS Utenti che acquistano o amministrano un tenant dell'applicazione. Joe, proprietario di Fourth Coffee Shop.
Utente del cliente SaaS Gli utenti che usano un tenant dell'applicazione senza amministrarlo e in genere appartengono alla stessa società o gruppo 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 admin e l'app SaaS sono entrambe applicazioni front-end.

Flusso di lavoro

  1. L'amministratore del cliente SaaS passa al sito ospitato nell'app Onboarding &admin.

  2. L'amministratore del cliente SaaS accede usando il flusso di lavoro di accesso dell'utente.

  3. L'amministratore del cliente SaaS completa il flusso di onboarding.

  4. 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.

  5. 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:

Diagramma di sequenza che mostra il processo di accesso per un utente.

  1. L'utente finale passa a un'applicazione front-end e seleziona un pulsante Di accesso.

  2. L'applicazione Front-end reindirizza l'utente finale a una pagina di accesso ospitata dal provider di identità.

  3. L'utente finale immette le informazioni sull'account e invia il modulo di accesso al provider di identità.

  4. Il provider di identitàinvia una richiesta POST con l'indirizzo di posta elettronica e l'ID oggetto dell'utente finale per recuperare le autorizzazioni e i ruoli.

  5. L'API Dati autorizzazione cerca le informazioni dell'utente finalenell'archiviazione dei dati delle autorizzazioni e restituisce un elenco di autorizzazioni e ruoli assegnati all'utente finale.

  6. Il provider di identità aggiunge le autorizzazioni e i ruoli come attestazioni personalizzate al token ID, ovvero un token Web JSON (JWT).

  7. Il provider di identità restituisce un token ID all'utente finale e avvia un reindirizzamento all'applicazione front-end.

  8. L'utente finale viene reindirizzato all'endpoint di accesso nell'applicazione front-end e presenta il token ID.

  9. L'applicazione Front-end convalida il token ID presentato.

  10. 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 Connect.

Eseguire l'onboarding di un nuovo tenant

Il flusso di lavoro di onboarding del tenant è costituito dai passaggi seguenti:

Diagramma sequenza che mostra il processo di onboarding del tenant.

  1. L'amministratore del cliente SaaS passa all'app Onboarding &admin e completa un modulo di iscrizione.

  2. L'app Onboarding &admin invia una richiesta POST all'API dati tenant per creare un nuovo tenant.

  3. L'API dati tenant crea un nuovo tenant nell'archiviazione dei dati del tenant.

  4. 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.

  5. L'API Dati autorizzazione crea un nuovo record di autorizzazione nell'archivio dati di autorizzazione.

  6. L'API dati di autorizzazione restituisce correttamente.

  7. L'API dati tenant restituisce correttamente.

  8. 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.

  9. Il provider di notifiche tramite posta elettronica invia il messaggio di posta elettronica.

  10. Il provider di notifica tramite posta elettronica restituisce correttamente.

  11. 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.

  12. Il provider di identità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.

  13. L'API Dati autorizzazione cerca le informazioni dell'amministratore del cliente SaaSnell'archiviazione dei dati delle autorizzazioni e restituisce un elenco di autorizzazioni e ruoli assegnati all'amministratore del cliente SaaS.

  14. Il provider di identità aggiunge le autorizzazioni e i ruoli come attestazioni personalizzate al token ID.

  15. Il provider di identità restituisce il token ID all'app Onboarding & Admin.

  16. L'app Onboarding &admin restituisce un messaggio di esito positivo e un nuovo token ID all'amministratore del cliente SaaS.

Aggiungere un utente a un tenant

L'aggiunta di un utente a un flusso di lavoro tenant è costituita dai passaggi seguenti:

Diagramma sequenza che mostra l'aggiunta di un nuovo utente a un tenant.

  1. L'amministratore del cliente SaaS richiede di visualizzare un elenco di tenant dall'area di amministrazione del tenant nell'app Onboarding &admin.

  2. L'app Onboarding &admin invia una richiesta GET all'API dati tenant per ottenere un elenco di tenant per l'amministratore del cliente SaaS.

  3. 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.

  4. L'API Dati autorizzazione restituisce un elenco di autorizzazioni del tenant.

  5. 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.

  6. L'app Onboarding &admin restituisce l'elenco dei dati del tenant all'amministratore del cliente SaaS.

  7. 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.

  8. L'app Onboarding &admin invia una richiesta POST all'APIdati tenant per aggiungere un'autorizzazione per l'utentedel cliente SaaS nel tenant specificato.

  9. 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.

  10. 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.

  11. 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.

  12. Il provider di identità restituisce l'ID oggetto dell'utente del cliente SaaS.

  13. 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.

  14. L'API dati di autorizzazione restituisce correttamente.

  15. L'API dati tenant restituisce correttamente.

  16. 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.

  • Il database SQL di Azure è un servizio gestito di database relazionale per utilizzo generico che supporta dati relazionali, dati spaziali, JSON e XML.

  • App per la logica di Azure consente di creare rapidamente potenti integrazioni usando un semplice strumento di interfaccia utente grafica (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 set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la 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 è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione 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 di 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 di Microsoft Entra External ID.

  • 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 del database SQL di Azure.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'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 della piattaforma Azure (piattaforma distribuita come servizio, PaaS), 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:

Altri contributori:

Passaggi successivi

Ecco alcune risorse aggiuntive consigliate per la creazione di un'applicazione SaaS in Azure: