Editar

Share via


Aplicação Web inicial para desenvolvimento SaaS

Azure App Service
ID Externa do Microsoft Entra
Azure SQL Database
Azure Logic Apps
Azure Resource Manager

Software as a Service (SaaS) é um tópico complexo com muitos pontos a considerar. Os fornecedores independentes de software (ISVs) que criam as suas soluções SaaS no Azure precisam de resolver problemas e tomar decisões como:

  • Que modelo de arrendamento devo utilizar?
  • Como configuro uma solução de identidade para uso em uma arquitetura multilocatário?
  • Como lidar com a integração de novos clientes?

Esta arquitetura visa responder a algumas destas questões e fornecer um ponto de partida para o mundo do SaaS. Esta arquitetura é adaptável para se adequar a uma ampla gama de cenários.

Potenciais casos de utilização

A seguir estão alguns exemplos de casos de uso em que você pode usar essa arquitetura:

  • Modernize um aplicativo existente para oferecer suporte à multilocação total como parte de uma mudança para um modelo de negócios baseado em SaaS.
  • Desenvolva uma oferta SaaS completamente nova.
  • Migre uma oferta SaaS de outro serviço de nuvem para o Azure.

Arquitetura

Diagrama de arquitetura que mostra o plano de controle, a estrutura de identidade e o aplicativo S a S do usuário final.

Transfira um ficheiro PowerPoint desta arquitetura.

Terminologia

A tabela a seguir descreve os termos que aparecem neste artigo.

Termo Description Exemplo
Fornecedor de SaaS ou ISV A entidade que possui o aplicativo e o código SaaS e vende o produto SaaS. Contoso Inc, vendendo seu aplicativo SaaS: Contoso Tickets.
Inquilino Uma instância comprada do aplicativo SaaS do fornecedor de SaaS. Quarto café.
Administrador de clientes SaaS Pessoas que compram ou administram um locatário de aplicativo. Joe, proprietário da Fourth Coffee Shop.
Usuário cliente SaaS Pessoas que usam um locatário de aplicativo sem administrá-lo e geralmente pertencem à mesma empresa ou grupo que o administrador do cliente SaaS. Jill, gerente de eventos da Fourth Coffee Shop, e Susan, cliente da Fourth Coffee Shop.
Utilizador final Um administrador de cliente SaaS, usuário cliente SaaS ou qualquer outro tipo de usuário que seja introduzido. Este é um termo genérico para descrever os usuários que entram no aplicativo. Joe, Jill e Susan são todos usuários finais (da perspetiva do ISV).
Aplicação front-end Qualquer aplicativo front-end. O aplicativo Onboarding & admin e o aplicativo SaaS são aplicativos front-end.

Fluxo de Trabalho

  1. O administrador do cliente SaaS navega até o site hospedado no aplicativo Onboarding & admin.

  2. O administrador do cliente SaaS entra usando o fluxo de trabalho de entrada do usuário.

  3. O administrador do cliente SaaS conclui o fluxo de integração.

  4. O administrador do cliente SaaS navega até a área de administração do locatário no aplicativo Onboarding & admin e adiciona um usuário cliente SaaS ao locatário recém-criado.

  5. O usuário cliente SaaS navega para o aplicativo SaaS e usa o aplicativo SaaS.

Início de sessão do utilizador

O fluxo de trabalho de entrada do usuário consiste nas seguintes etapas:

Diagrama de sequência que mostra o processo de entrada de um usuário.

  1. O usuário final navega até um aplicativo front-end e seleciona um botão Login .

  2. O aplicativo front-end redireciona o usuário final para uma página de entrada hospedada pelo provedor de identidade.

  3. O Utilizador Final introduz informações da conta e submete o formulário de início de sessão ao fornecedor de Identidade.

  4. O provedor deidentidade emite uma solicitação POST com o endereço de e-mail e a ID do objeto do usuário final para recuperar suas permissões e funções.

  5. A API de dados de permissão procura as informações do usuário final no armazenamento de dados de permissão e retorna uma lista de permissões e funções atribuídas a esse usuário final.

  6. O provedor de identidade adiciona as permissões e funções como declarações personalizadas ao token de ID, que é um token da Web JSON (JWT).

  7. O provedor de identidade retorna um token de ID para o usuário final e inicia um redirecionamento para o aplicativo front-end.

  8. O usuário final é redirecionado para o ponto de extremidade de entrada no aplicativo front-end e apresenta o token de ID.

  9. O aplicativo front-end valida o token de ID apresentado.

  10. O aplicativo front-end retorna uma página de entrada bem-sucedida e o usuário final agora está conectado.

Para obter mais informações sobre como esse fluxo de entrada funciona, consulte Protocolo OpenID Connect.

A bordo de um novo inquilino

O fluxo de trabalho de integração do locatário consiste nas seguintes etapas:

Diagrama de sequência que mostra o processo de integração do locatário.

  1. O administrador do cliente SaaS navega até o aplicativo Onboarding & admin e preenche um formulário de inscrição.

  2. O aplicativo Onboarding & admin emite uma solicitação POST para a API de dados do locatário para criar um novo locatário.

  3. A API de dados do locatário cria um novo locatário no armazenamento de dados do locatário.

  4. A API de dados do locatário emite uma solicitação POST para a API de dados de permissão para conceder permissões de administrador do cliente SaaS ao locatário recém-criado.

  5. A API de dados de permissão cria um novo registro de permissão no armazenamento de dados de permissão.

  6. A API de dados de permissão retorna com êxito.

  7. A API de dados do locatário retorna com êxito.

  8. O aplicativo Onboarding & admin emite uma solicitação POST para o provedor de notificação por e-mail para enviar uma mensagem de e-mail "tenant created" para o administrador do cliente SaaS.

  9. O provedor de notificação por e-mail envia o e-mail.

  10. O provedor de notificação por e-mail retorna com êxito.

  11. O aplicativo Onboarding & admin emite uma solicitação ao provedor de Identidade para atualizar o token de ID do administrador do cliente SaaS para que ele inclua uma reivindicação JWT para o locatário recém-criado.

  12. O provedorde identidade emite uma solicitação POST com o endereço de e-mail e a ID do objeto do administrador do cliente SaaS para recuperar suas permissões e funções.

  13. A API de dados de permissão procura as informações do administrador do cliente SaaS no armazenamento de dados de permissão e retorna uma lista de permissões e funções atribuídas ao administrador do cliente SaaS.

  14. O provedor de identidade adiciona as permissões e funções como declarações personalizadas ao token de ID.

  15. O provedor de identidade retorna o token de ID para o aplicativo Onboarding & Admin.

  16. O aplicativo Onboarding & admin retorna uma mensagem de sucesso e um novo token de ID para o administrador do cliente SaaS.

Adicionar um utilizador a um inquilino

A adição de um usuário a um fluxo de trabalho de locatário consiste nas seguintes etapas:

Diagrama de sequência que mostra a adição de um novo usuário a um locatário.

  1. O administrador do cliente SaaS solicita para ver uma lista de locatários da área de administração do locatário no aplicativo Onboarding & admin.

  2. O aplicativo Onboarding & admin emite uma solicitação GET para a API de dados do locatário para obter uma lista de locatários para o administrador do cliente SaaS.

  3. A API de dados do locatário emite uma solicitação GET para a API de dados de permissão para obter uma lista de locatários que o administrador do cliente SaaS tem acesso para exibir.

  4. A API de dados de permissão retorna uma lista de permissões de locatário.

  5. A API de dados do locatário procura as informações do locatário no armazenamento de dados do locatário e retorna uma lista de dados do locatário com base na lista de permissões de locatário recebidas.

  6. O aplicativo Onboarding & admin retorna a lista de dados do locatário para o administrador do cliente SaaS.

  7. O administrador do cliente SaaS seleciona um locatário da lista para adicionar um usuário cliente SaaS e insere o endereço de e-mail do usuário cliente SaaS.

  8. O aplicativo Onboarding & admin emite uma solicitação POST para a API de dados do locatário para adicionar uma permissão para o usuário cliente SaaS no locatário especificado.

  9. A API de dados do locatário verifica se o administrador do cliente SaaS tem uma reivindicação JWT válida para o locatário especificado e tem a permissão de gravação do usuário nele.

  10. A API de dados do locatário emite uma solicitação POST para a API de dados de permissão para adicionar uma permissão para o usuário cliente SaaS no locatário especificado.

  11. A API de dados de permissão emite uma solicitação GET para o provedor de identidade para procurar o usuário cliente SaaS pelo endereço de e-mail fornecido.

  12. O provedor de identidade retorna a ID de objeto do usuário cliente SaaS.

  13. A API de dados de permissão adiciona um registro de permissão no armazenamento de dados de permissão para o usuário cliente SaaS no locatário especificado usando sua ID de objeto.

  14. A API de dados de permissão retorna com êxito.

  15. A API de dados do locatário retorna com êxito.

  16. O aplicativo Onboarding & admin retorna com êxito.

Componentes

Essa arquitetura usa os seguintes serviços do Azure:

  • O Serviço de Aplicativo permite que você crie e hospede aplicativos Web e aplicativos de API na linguagem de programação escolhida sem a necessidade de gerenciar a infraestrutura.

  • O Azure Ative Directory B2C habilita facilmente o gerenciamento de identidade e acesso para aplicativos de usuário final.

  • O Banco de Dados SQL do Azure é um serviço gerenciado de banco de dados relacional de uso geral que dá suporte a dados relacionais, dados espaciais, JSON e XML.

  • As Aplicações Lógicas do Azure permitem-lhe criar rapidamente integrações poderosas utilizando uma ferramenta GUI simples.

Alternativas

A eficácia de quaisquer escolhas alternativas depende muito do modelo de arrendamento que pretende que a sua aplicação SaaS suporte. A seguir estão alguns exemplos de abordagens alternativas que você pode seguir ao implementar essa solução:

  • A solução atual usa o Azure Ative Directory B2C como o provedor de identidade. Em vez disso, você pode usar outros provedores de identidade, como o Microsoft Entra ID.

  • Para requisitos mais rígidos de segurança e conformidade, você pode optar por implementar redes privadas para comunicação entre serviços.

  • Em vez de usar chamadas REST entre serviços, você pode implementar um estilo de arquitetura controlado por eventos para mensagens entre serviços.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode seguir para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Esta solução baseia-se na identidade como paradigma de segurança. A autenticação e a autorização para os aplicativos Web e APIs são regidas pela plataforma de identidade da Microsoft, que é responsável pela emissão e verificação de tokens de ID de usuário (JWTs).

Otimização de custos

A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.

Os componentes desta solução têm algum custo associado à sua operação, mas o custo é modesto para a maioria das aplicações web e soluções SaaS. Além disso, você pode controlar o custo gerenciando as seguintes configurações de recursos:

  • Você pode dimensionar o plano do Serviço de Aplicativo que executa o aplicativo para se ajustar à taxa de transferência necessária. Além disso, você pode executar cada aplicativo em um plano separado se precisar de uma taxa de transferência mais alta, mas incorrerá em um custo mais alto como resultado. Para obter mais informações, consulte Visão geral do plano do Serviço de Aplicativo do Azure.

  • O Azure AD B2C fornece duas SKUs: Premium P1 e Premium P2. Ambos os SKUs incluem uma franquia gratuita para o número de usuários ativos mensais (MAUs), mas você precisa avaliar quais recursos cada SKU fornece para determinar quais são necessários para seu caso de uso. Para obter mais informações, consulte Preços de ID Externa do Microsoft Entra.

  • O Azure SQL tem vários modelos de compra para se adequar a uma ampla variedade de casos de uso, incluindo a capacidade de dimensionamento automático. Você precisa avaliar o uso em seus próprios bancos de dados para garantir que você os dimensione corretamente. Para obter mais informações, consulte Comparar modelos de compra baseados em vCore e DTU do Banco de Dados SQL do Azure.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

Essa arquitetura deve ser capaz de ser dimensionada para atender facilmente à maioria das cargas de trabalho de médio a médio e grande porte. Como a arquitetura usa principalmente os serviços de plataforma (PaaS) do Azure, você tem muitas opções para ajustar a escala da solução com base em seus requisitos e carga.

Implementar este cenário

Se você quiser implantar esse cenário, consulte o Kit de Desenvolvimento SaaS do Azure no GitHub. É uma implementação de referência implantável dessa arquitetura.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Outros contribuidores:

Próximos passos

Aqui estão alguns recursos adicionais recomendados para criar um aplicativo SaaS no Azure: