Añadiendo features

Autenticación y autorización

La feature de autenticación agrega la base de seguridad utilizada por los proyectos Lino para proteger los API, identificar usuarios, controlar el acceso a las operaciones e integrar los mismos permisos con las aplicaciones web Blazor. Se instala con el comando:

lino feature auth add --service <ServiceName> --module <ModuleName>

El comando también se puede ejecutar de forma interactiva con lino feature auth add. La rama canónica es feature auth; CLI también expone alias como feature security y feature identity.

En la arquitectura actual Lino, la autenticación y la autorización se basan en mensajes asincrónicos. El motivo es operativo: los permisos de servicio y módulo se sincronizan mediante eventos de integración, por lo que el proyecto debe tener habilitada la mensajería antes de agregar seguridad.

Lo que pide el mago

CLI valida el proyecto actual, verifica si la feature aún no se ha instalado, pregunta dónde se debe crear el módulo de seguridad y solicita la configuración del token principal.

• Servicio: servicio que alojará los recursos de seguridad.
• Módulo: módulo de destino cuando el servicio seleccionado es modular.
• Duración del token de acceso: vida útil, en minutos, de los tokens de acceso emitidos.
• Actualizar la vida útil del token: vida útil de los tokens utilizados para renovar las sesiones.
• Tipo de identificador de usuario: tipo de datos utilizados como identificador de usuario, como int, long o Guid.

Modelo de seguridad generado

Después de la confirmación, Lino actualiza los metadatos del proyecto, crea valores de configuración de seguridad, genera archivos de código fuente y ejecuta los comandos necesarios. El modelo generado incluye las entidades centrales de seguridad:

• User almacena identidades y datos de perfil.
• Role y asociaciones de roles para reglas de acceso a grupos.
• Permission y relaciones entre roles y permisos para autorización granular.
• UserToken para controlar los tokens de actualización y el ciclo de vida de los tokens.

La feature también crea la información necesaria para la configuración de seguridad, como el secreto para firmar tokens y los tiempos de vida del access token y del refresh token. Los valores confidenciales se emiten como comandos para los secretos de usuario de AppHost, en lugar de escribirse directamente en archivos versionados.

Comportamiento en tiempo de ejecución

La API utiliza autenticación JWT Bearer. El usuario inicia sesión, recibe un access token y un refresh token, y comienza a enviar solicitudes a la API con el header Authorization: Bearer <token>. El backend valida el token, carga el contexto del usuario y aplica reglas de autorización a los endpoints.

El flujo típico sigue siendo simple: iniciar sesión a través de un punto final o una página dedicada, emitir JWT con reclamos de identidad, roles y permisos, enviar el token en cada solicitud y validar la firma y el vencimiento a través del middleware de autenticación.

Lino utiliza políticas y permisos para implementar autorización granular. Cada acción puede requerir un permiso específico, como People.Read o People.Create; Las políticas se pueden configurar a través de AddAuthorization; y los endpoints se pueden proteger declarando .RequireAuthorization.

Los endpoints y las páginas generados utilizan permisos de forma coherente. Las operaciones de backend pueden requerir permisos, mientras que la interfaz de usuario Blazor generada puede cargar permisos, proteger páginas, ocultar acciones no disponibles y exponer pantallas para usuarios, roles, permisos y autorizaciones cuando hay una aplicación web en el proyecto.

Cuando los Background Jobs ya están habilitados, Lino también agrega trabajos relacionados con tokens de usuario, como rutinas de mantenimiento para tokens deshabilitados o vencidos.

Procesamiento en segundo plano y Outbox

El procesamiento en segundo plano maneja el trabajo que no debería bloquear el flujo principal de solicitud y respuesta: publicar eventos de integración, limpiar registros antiguos, eliminar tokens caducados, enviar notificaciones, generar informes, sincronizar con sistemas externos o ejecutar tareas programadas. Lino agrega esta capacidad a través de la feature de trabajo en segundo plano:

lino feature background-job add --service <ServiceName>

El comando también se puede ejecutar como lino feature background-job add y completarse de forma interactiva. CLI expone alias como job-scheduler y worker.

Esta feature requiere que la mensajería esté habilitada en el proyecto, porque su principal responsabilidad es publicar de forma segura los mensajes registrados por el estándar Transaccional Outbox.

Lo que pide el mago

• Servicio: servicio en el que se instalará la infraestructura de Background Jobs.
• Biblioteca de Background Jobs: implementación utilizada para ejecutar y programar trabajos. La infraestructura generada actualmente utiliza Hangfire.
• Procesamiento Outbox: define si el servicio registrará eventos para ser procesados ​​por el planificador.
• CronOutboxMensajes: expresión de rango o programación utilizada para comprobar si hay mensajes nuevos Outbox.
• Tamaño de lote: número de registros Outbox recuperados y procesados ​​por ciclo, controlando carga, paralelismo y consumo de recursos.

Infraestructura Hangfire

Lino genera la infraestructura necesaria para registrar Hangfire, configurar su persistencia, exponer el panel y programar los trabajos utilizados por el servicio. La configuración generada incluye la información necesaria para programar jobs, procesar mensajes Outbox y proteger el acceso al panel del programador.

En las soluciones generadas, el esquema y las tablas Hangfire forman parte de la configuración de la base de datos de la aplicación. El panel lo ayuda a inspeccionar trabajos completados, fallidos, programados y recurrentes durante el desarrollo y la operación.

Los beneficios prácticos incluyen la ejecución confiable de tareas asincrónicas, un panel de monitoreo integrado, soporte para trabajos recurrentes o programados y persistencia de trabajos en la base de datos.

Procesamiento con Outbox transaccional

Para garantizar la coherencia en las integraciones asincrónicas, Lino utiliza el patrón transaccional Outbox. Un caso de uso empresarial persiste los cambios de dominio y registra un evento de integración en la tabla Outbox dentro de la misma transacción. Luego, el trabajo en segundo plano lee la tabla Outbox y publica el evento a través del bus de mensajes configurado, como RabbitMQ con MassTransit cuando se han seleccionado estas opciones para el proyecto.

1. Un comando cambia el estado del dominio y guarda este cambio en una transacción.
2. Un controlador registra un evento de integración en Outbox, por ejemplo un evento relacionado con la creación de un pedido.
3. El trabajo Hangfire bloquea un lote de mensajes no procesados ​​y los marca como en proceso.
4. Cada mensaje es deserializado y publicado por el bus de eventos.
5. Los mensajes exitosos se marcan como procesados; Los mensajes fallidos conservan la información del error para un análisis posterior o una estrategia de reintento.

El resultado es atomicidad entre la base de datos y los eventos registrados, confiabilidad para que los eventos no se pierdan en caso de falla y escalabilidad para que múltiples consumidores procesen los mensajes publicados.

El trabajo generado también incluye rutinas para eliminar mensajes Outbox antiguos que ya se procesaron exitosamente y liberar mensajes que estaban bloqueados en el procesamiento, lo que reduce el riesgo de bloqueos permanentes después de fallas en la aplicación.

Cuando se instala la autenticación, la feature de trabajo en segundo plano también puede albergar trabajos de mantenimiento de tokens, manteniendo limpios los datos de seguridad con el tiempo.

Con estas features adicionales, Lino ofrece seguridad sólida, control de acceso granular y procesamiento asincrónico confiable para requisitos críticos de aplicaciones de producción modernas.

multi-tenancy

Multi-tenancy es la feature que se utiliza cuando la misma aplicación necesita servir a múltiples clientes, organizaciones o entornos mientras mantiene datos, permisos y configuraciones aislados para cada tenant. En Lino, se agrega soporte para tenants con:

lino feature tenant add --service <ServiceName> --module <ModuleName>

El comando también se puede ejecutar de forma interactiva con lino feature tenant add. La rama del CLI también expone alias como tenancy.

Requisitos previos

El soporte para tenants depende de dos capacidades arquitectónicas:

• Autenticación y autorización, porque el acceso de los usuarios, las funciones, los permisos y los tokens deben tener en cuenta los tenants.
• Mensajería, porque la información de tenants y usuarios se puede propagar a otros módulos mediante eventos de integración.

Si faltan estos requisitos previos, el comando se rechaza. La feature también se puede instalar solo una vez por proyecto.

Qué se genera

Lino crea el modelo de tenancy, la configuración, los eventos, la integración de API y los recursos de interfaz necesarios para administrar los tenants de manera consistente.

• Tenant almacena la identidad del tenant, el nombre, el slug, el estado, el modo de aislamiento y la referencia de la cadena de conexión.
• TenantBranding almacena datos de marca para un comportamiento visual específico por tenant.
• TenantDomain asigna hosts o dominios a tenants.
• TenantStatus y IsolationMode definen el ciclo de vida del tenant y las opciones de aislamiento de datos.
• La configuración generada admite la resolución de tenants y el aislamiento de datos del proyecto.

Seguridad tenant-aware

El tenancy cambia la forma en que se interpretan la autenticación y la autorización. Un token y un permiso válidos se evalúan dentro del contexto del tenant actual; un usuario con acceso en un tenant no recibe automáticamente acceso a otro tenant. Por lo tanto, el soporte para tenants actualiza los flujos de autenticación, el comportamiento del token de actualización, los permisos y las referencias generadas para la interfaz de usuario.

En las aplicaciones Blazor generadas, se pueden agregar pantallas de tenant-aware para administrar tenants y flujos de autorización. En el backend, los endpoints generados pueden resolver el contexto del tenant a partir del comportamiento de ruta, slug o host configurado y luego aplicar el identificador del tenant en las decisiones de autorización y datos.

Aislamiento y propagación de datos.

Lino admite el modelado de dominios consciente de los tenants al permitir que las entidades declaren la propiedad por tenant. En escenarios SaaS, esto permite que las tablas comerciales almacenen datos específicos del tenant mientras los módulos compartidos continúan recibiendo la información del tenant y del usuario que necesitan.

La arquitectura generada utiliza eventos y el patrón Outbox para propagar datos de usuarios o tenants seleccionados entre módulos sin acoplar todos los módulos directamente a las tablas de identidad o tenancy originales. Esto mantiene claros los límites del módulo, mientras que las pantallas, API, permisos y consultas continúan funcionando con el contexto del tenant.

Después de agregar el tenancy, cree y aplique migraciones para el servicio afectado, revise los secretos generados y las claves API, ejecute AppHost y valide con al menos dos tenants para garantizar que los datos, usuarios, roles, permisos y registros comerciales permanezcan aislados.

• Validar aislamiento: cree pruebas intentando acceder a datos de otro tenant.
• Revise permisos: un usuario puede tener diferentes roles en diferentes tenants.
• Evite confiar en el cliente: El tenant informado por ruta, host, slug o header debe ser compatible con el usuario autenticado.