Editar

Compartir a través de


Aplicación web de inicio para el desarrollo de SaaS

Azure App Service
Id. externa de Microsoft Entra
Azure SQL Database
Azure Logic Apps
Azure Resource Manager

El software como servicio (SaaS) es un tema complejo con muchos aspectos a tener en cuenta. Los proveedores de software independientes (ISV) que compilan sus soluciones SaaS en Azure necesitan resolver problemas y tomar decisiones como:

  • ¿Qué modelo de inquilinato debería usar?
  • ¿Cómo configuro una solución de identidad para su uso en una arquitectura multiinquilino?
  • ¿Cómo controlo la incorporación de nuevos clientes?

Esta arquitectura tiene como objetivo responder a algunas de estas preguntas y proporcionar un punto de partida en el entorno SaaS. Esta arquitectura se puede adaptar a una amplia gama de escenarios.

Posibles casos de uso

A continuación se muestran algunos casos de uso de ejemplo en los que podría usar esta arquitectura:

  • Modernización de una aplicación existente para que admita el modelo de multiinquilinato completo como parte de un cambio a un modelo de negocio basado en SaaS.
  • Desarrollo de una oferta de SaaS completamente nueva.
  • Migración de una oferta de SaaS desde otro servicio en la nube a Azure.

Architecture

Diagrama de arquitectura que muestra el plano de control, el marco de identidad y la aplicación SaaS del usuario final.

Descargue un archivo de PowerPoint de esta arquitectura.

Terminología

En la tabla siguiente se describen los términos que aparecen en este artículo.

Término Descripción Ejemplo
Proveedor de SaaS o proveedor de software independiente (ISV) La entidad que posee la aplicación SaaS y el código, y que vende el producto SaaS. Contoso Inc, en la venta de su aplicación SaaS: Contoso Tickets.
Inquilino Una instancia adquirida de la aplicación SaaS del proveedor de SaaS. Fourth Coffee Shop.
Administrador del cliente de SaaS Persona que compra o administra un inquilino de aplicación. Joe, propietario de Fourth Coffee Shop.
Usuario del cliente de SaaS Personas que usan un inquilino de aplicación sin administrarlo y que normalmente pertenecen a la misma empresa o grupo que el administrador del cliente de SaaS. Jill, gerente de eventos en Fourth Coffee Shop y Susan, cliente de Fourth Coffee Shop.
Usuario final Un administrador o un usuario de cliente de SaaS, o cualquier otro tipo de usuario que se introduzca. Se trata de un término genérico para describir a los usuarios que inician sesión en la aplicación. Joe, Jill y Susan son todos usuarios finales (desde la perspectiva del ISV).
Aplicación front-end Cualquier aplicación de front-end. La aplicación de incorporación y administración, y la aplicación SaaS son aplicaciones de front-end.

Flujo de trabajo

  1. El administrador del cliente de SaaS va al sitio que se hospeda en la aplicación de incorporación y administración.

  2. El administrador del cliente de SaaS inicia sesión mediante el flujo de trabajo de inicio de sesión del usuario.

  3. El administrador del cliente de SaaS realiza el flujo de incorporación.

  4. El administrador del cliente de SaaS va al área de administración del inquilino en la aplicación de incorporación y administración y agrega un usuario de cliente de SaaS a su inquilino recién creado.

  5. El usuario de cliente de SaaS va a la aplicación SaaS y la utiliza.

Inicio de sesión de usuario

El flujo de trabajo de inicio de sesión de usuario consta de los pasos siguientes:

Diagrama de secuencias que muestra el proceso de inicio de sesión para un usuario.

  1. El usuario final va a una aplicación de front-end y selecciona el botón Iniciar sesión.

  2. La aplicación de front-end redirige al usuario final a una página de inicio de sesión que hospeda el proveedor de identidades.

  3. El usuario final especifica la información de la cuenta y envía el formulario de inicio de sesión al proveedor de identidades.

  4. El proveedor de identidad emite una solicitud POST con la dirección de correo electrónico del usuario finaly el ID del objeto para recuperar sus permisos y roles.

  5. La API de datos de permisos busca la información del usuario final en el almacenamiento de datos de permisos y devuelve una lista de los permisos y roles asignados a ese usuario final.

  6. El proveedor de identidades agrega los permisos y roles como notificaciones personalizadas al token de identificador, que es una instancia de JSON Web Token (JWT).

  7. El proveedor de identidades devuelve un token de identificador al usuario final e inicia una redirección a la aplicación de front-end.

  8. Se redirige al usuario final al punto de conexión de inicio de sesión en la aplicación de front-end y se presenta el token de identificador.

  9. La aplicación de front-end valida el token de identificador presentado.

  10. La aplicación de front-end devuelve una página de inicio de sesión correcta y se considera ya que el usuario final ha iniciado sesión.

Para más información sobre cómo funciona este flujo de inicio de sesión, consulte el protocolo de OpenID Connect.

Incorporación de un nuevo inquilino

Un flujo de trabajo de incorporación de inquilino consta de los siguientes pasos:

Diagrama de secuencias que muestra el proceso de incorporación de inquilino.

  1. El administrador del cliente de SaaS va a la aplicación de incorporación y administración y rellena un formulario de registro.

  2. La aplicación de incorporación y administración emite una solicitud POST a la API de datos de inquilino para crear un nuevo inquilino.

  3. La API de datos de inquilino crea un nuevo inquilino en el almacenamiento de datos del inquilino.

  4. La API de datos de inquilino emite una solicitud POST a la API de datos de permisos para conceder permisos de administrador de clientes de SaaS al inquilino recién creado.

  5. La API de datos de permisos crea un nuevo registro de permisos en el almacenamiento de datos de permisos.

  6. La API de datos de permisos devuelve una respuesta correcta.

  7. La API de datos de inquilino devuelve una respuesta correcta.

  8. La aplicación de incorporación y administración emite una solicitud POST al proveedor de notificaciones por correo electrónico para que envíe un mensaje de correo electrónico "creado por el inquilino" al administrador del cliente de SaaS.

  9. El proveedor de notificaciones por correo electrónico envía el correo electrónico.

  10. El proveedor de notificaciones por correo electrónico devuelve una respuesta correcta.

  11. La aplicación de incorporación y administración emite una solicitud al proveedor de identidades para que actualice el token de identificador del administrador del cliente de SaaS para que incluya una notificación JWT al inquilino recién creado.

  12. El proveedor de identidad emite una solicitud POST con la dirección de correo electrónico del administrador de cliente de SaaSy el ID del objeto para recuperar sus permisos y roles.

  13. La API de datos de permisos busca la información del administrador del cliente de SaaS en el almacenamiento de datos de permisos y devuelve una lista de los permisos y roles asignados a este administrador.

  14. El proveedor de identidades agrega los permisos y roles como notificaciones personalizadas al token de identificador.

  15. El proveedor de identidades devuelve el token de identificador a la aplicación de incorporación y administración.

  16. La aplicación de incorporación y administración devuelve un mensaje de confirmación y un nuevo token de identificador al administrador del cliente de SaaS.

Incorporación de un usuario a un inquilino

La adición de un usuario a un flujo de trabajo de inquilino consta de los pasos siguientes:

Diagrama de secuencias que muestra cómo añadir un nuevo usuario a un inquilino.

  1. El administrador del cliente de SaaS solicita ver una lista de inquilinos del área de administración de inquilinos de la aplicación de incorporación y administración.

  2. La aplicación de incorporación y administración emite una solicitud GET a la API de datos de inquilino para obtener una lista de los inquilinos del administrador del cliente de SaaS.

  3. La API de datos de inquilino emite una solicitud GET a la API de datos de permisos para obtener una lista de inquilinos a los que el administrador del cliente de SaaS tiene acceso.

  4. La API de datos de permisos devuelve una lista de permisos de inquilino.

  5. La API de datos de inquilino busca la información del inquilino en el almacenamiento de datos del inquilino y devuelve una lista de datos de inquilino en función de la lista de permisos de inquilino recibidos.

  6. La aplicación de incorporación y administración devuelve la lista de datos de inquilino al administrador de clientes de SaaS.

  7. El administrador del cliente de SaaS selecciona un inquilino de la lista al que agregar un usuario de cliente de SaaS y especifica la dirección de correo electrónico del usuario de cliente de SaaS.

  8. La aplicación de incorporación y administración emite una solicitud POST a la API de datos de inquilino para que agregue un permiso para el usuario del cliente de SaaS en el inquilino especificado.

  9. La API de datos de inquilino comprueba que el administrador del cliente de SaaS tiene una notificación JWT válida para el inquilino especificado y que tiene un permiso de escritura del usuario en dicho inquilino.

  10. La API de datos de inquilino emite una solicitud POST a la API de datos de permiso para que agregue un permiso para el usuario del cliente de SaaS en el inquilino especificado.

  11. La API de datos de permisos emite una solicitud GET al proveedor de identidades para que busque el usuario del cliente de SaaS mediante la dirección de correo electrónico proporcionada.

  12. El proveedor de identidades devuelve el identificador de objeto del usuario del cliente de SaaS.

  13. La API de datos de permisos agrega un registro de permisos en el almacenamiento de datos de permisos para el usuario del cliente de SaaS en el inquilino especificado mediante su identificador de objeto.

  14. La API de datos de permisos devuelve una respuesta correcta.

  15. La API de datos de inquilino devuelve una respuesta correcta.

  16. La aplicación de incorporación y administración devuelve una respuesta correcta.

Componentes

Esta arquitectura emplea los siguientes servicios de Azure:

  • App Service le permite crear y hospedar aplicaciones web y aplicaciones de API en el lenguaje de programación que elija sin necesidad de administrar la infraestructura.

  • Azure Active Directory B2C permite fácilmente la administración de identidades y acceso para las aplicaciones de usuario final.

  • Azure SQL Database es un servicio administrado de base de datos relacional de uso general que admite datos relacionales, datos espaciales, JSON y XML.

  • Azure Logic Apps le permite crear rápidamente potentes integraciones mediante una sencilla herramienta de interfaz gráfica de usuario (GUI).

Alternativas

La eficacia de las opciones alternativas depende en gran medida del modelo de inquilinato que pretende que la aplicación SaaS admita. A continuación se muestran algunos ejemplos de enfoques alternativos que puede seguir al implementar esta solución:

  • La solución actual usa Azure Active Directory B2C como proveedor de identidades. En su lugar, podría usar otros proveedores de identidades, como Microsoft Entra ID.

  • Para obtener requisitos de seguridad y cumplimiento más estrictos, puede optar por implementar redes privadas para la comunicación entre servicios.

  • En lugar de usar llamadas REST entre servicios, podría implementar un estilo de arquitectura controlado por eventos para la mensajería entre servicios.

Consideraciones

Estas consideraciones permiten implementar los fundamentos del Marco de buena arquitectura de Azure, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

Esta solución se basa en la identidad como paradigma de seguridad. La autenticación y autorización de las aplicaciones web y las API se rige por la plataforma de identidad de Microsoft, que es la responsable de emitir y comprobar los tokens de identificador de usuario (JWT).

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Los componentes de esta solución tienen algún costo asociado a su funcionamiento, pero este costo no es elevado para la mayoría de aplicaciones web y soluciones de SaaS. Además, puede controlar el costo mediante la administración de los siguientes valores de los recursos:

  • Puede escalar el plan de App Service que ejecuta la aplicación para adaptarse al rendimiento que necesita. Además, puede ejecutar cada aplicación en un plan independiente si necesita un rendimiento mayor, pero incurrirá en un costo más elevado como resultado. Para más información, consulte Introducción a los planes de Azure App Service.

  • Azure AD B2C proporciona dos SKU: Premium P1 y Premium P2. Ambas SKU incluyen una asignación gratuita para el número de usuarios activos mensuales (MAU), pero debe evaluar qué características proporciona cada SKU para determinar cuáles son necesarias para su caso de uso. Para obtener más información, consulte Precios de Microsoft Entra External ID.

  • Azure SQL tiene varios modelos de compra para adaptarse a una amplia gama de casos de uso, y entre estos modelos se incluye la capacidad de la escalabilidad automática. Debe evaluar el uso en sus propias bases de datos para asegurarse de que ajusta el tamaño correctamente. Para más información, consulte Comparación de los modelos de compra basados en núcleos virtuales y DTU de Azure SQL Database.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para más información, consulte Información general sobre el pilar de eficiencia del rendimiento.

Esta arquitectura debe ser capaz de escalarse para satisfacer fácilmente las demandas de la mayoría de las cargas de trabajo medianas a grandes. Dado que la arquitectura usa principalmente los servicios de la plataforma como servicio (PaaS) de Azure, tiene muchas opciones para ajustar el escalado de la solución en función de sus requisitos y carga.

Implementación de este escenario

Si quiere implementar este escenario, consulte el Kit de desarrollo de SaaS de Azure en GitHub. Es una implementación de referencia implementable de esta arquitectura.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

Otros colaboradores:

Pasos siguientes

Estos son algunos recursos recomendados adicionales para crear una aplicación SaaS en Azure: