Добавление функций

Аутентификация и авторизация

Функция аутентификации добавляет основу безопасности, используемую проектами Lino для защиты API, идентификации пользователей, контроля доступа к операциям и интеграции тех же разрешений с веб-приложениями Blazor. Устанавливается командой:

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

Эту команду также можно выполнить в интерактивном режиме с помощью lino feature auth add. Каноническая ветвь – это feature auth; CLI также предоставляет псевдонимы, такие как feature security и feature identity.

В текущей архитектуре Lino аутентификация и авторизация полагаются на асинхронный обмен сообщениями. Причина оперативная: разрешения сервисов и модулей синхронизируются событиями интеграции, поэтому перед добавлением безопасности в проекте необходимо включить обмен сообщениями.

Что просит волшебник

CLI проверяет текущий проект, проверяет, не установлена ​​ли функция, спрашивает, где следует создать модуль безопасности, и запрашивает основные настройки токена.

• Услуга: служба, на которой будут размещаться ресурсы безопасности.
• Модуль: целевой модуль, если выбранная служба является модульной.
• Срок действия токена доступа: срок действия выданных токенов доступа в минутах.
• Обновить срок действия токена: срок действия токенов, используемых для возобновления сеансов.
• Тип идентификатора пользователя: тип данных, используемых в качестве идентификатора пользователя, например int, long или Guid.

Созданная модель безопасности

После подтверждения Lino обновляет метаданные проекта, создает значения конфигурации безопасности, генерирует файлы исходного кода и выполняет необходимые команды. Сгенерированная модель включает в себя центральные объекты безопасности:

• User хранит идентификационные данные и данные профиля.
• Role и ассоциации ролей для группировки правил доступа.
• Permission и отношения между ролями и разрешениями для детальной авторизации.
• UserToken для управления токенами обновления и жизненным циклом токена.

Эта функция также создает сведения, необходимые для настройки безопасности, например секрет для подписи токенов и сроки действия access token и refresh token. Чувствительные значения выдаются в виде команд для пользовательских секретов AppHost, а не записываются непосредственно в файлы с версиями.

Поведение во время выполнения

API использует JWT Bearer-аутентификацию. Пользователь входит в систему, получает access token и refresh token и отправляет запросы к API с заголовком Authorization: Bearer <token>. Серверная часть проверяет токен, загружает пользовательский контекст и применяет правила авторизации к конечным точкам.

Типичный процесс остается простым: вход в систему через конечную точку или выделенную страницу, выдача JWT с идентификационными утверждениями, ролями и разрешениями, отправка токена в каждом запросе и проверка подписи и срока действия с помощью промежуточного программного обеспечения аутентификации.

Lino использует политики и разрешения для реализации детальной авторизации. Для каждого действия может потребоваться особое разрешение, например People.Read или People.Create; Политики можно настроить через AddAuthorization; и endpoints можно защитить, объявив .RequireAuthorization.

Созданные endpoints и страницы последовательно используют разрешения. Для внутренних операций могут потребоваться разрешения, а сгенерированный пользовательский интерфейс Blazor может загружать разрешения, защищать страницы, скрывать недоступные действия и открывать экраны для пользователей, ролей, разрешений и авторизаций, если в проекте есть веб-приложение.

Если Background Jobs уже включены, Lino также добавляет задания, связанные с пользовательскими токенами, например процедуры обслуживания отключенных или просроченных токенов.

Background processing и Outbox

Background processing выполняет работу, которая не должна блокировать основной поток запросов и ответов: публикацию событий интеграции, очистку старых записей, удаление токенов с истекшим сроком действия, отправку уведомлений, создание отчетов, синхронизацию с внешними системами или выполнение запланированных задач. Lino добавляет эту возможность посредством функции фонового задания:

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

Команда также может быть выполнена как lino feature background-job add и завершено в интерактивном режиме. CLI предоставляет псевдонимы как job-scheduler и worker.

Для этой функции требуется, чтобы в проекте был включен обмен сообщениями, поскольку ее основная обязанность — безопасная публикация сообщений, зарегистрированных по стандарту Transactional Outbox.

Что просит волшебник

• Услуга: сервис, в котором будет установлена ​​инфраструктура фоновых заданий.
• Библиотека фоновых заданий: реализация, используемая для выполнения и планирования заданий. Созданная в настоящее время инфраструктура использует Hangfire.
• Outbox Обработка: определяет, будет ли служба регистрировать события для обработки планировщиком.
• CronOutboxСообщения: выражение диапазона или расписания, используемое для проверки наличия новых сообщений Outbox.
• Размер пакета: количество записей Outbox, полученных и обработанных за цикл, контролирующих нагрузку, параллелизм и потребление ресурсов.

Hangfire Инфраструктура

Lino создает необходимую инфраструктуру для регистрации Hangfire, настройки его устойчивости, предоставления панели мониторинга и планирования заданий, используемых службой. Сгенерированная конфигурация содержит сведения, необходимые для планирования jobs, обработки сообщений Outbox и защиты доступа к панели мониторинга планировщика.

В созданных решениях схема и таблицы Hangfire являются частью конфигурации базы данных приложения. Панель мониторинга помогает вам проверять выполненные, неудачные, запланированные и повторяющиеся задания во время разработки и эксплуатации.

Практические преимущества включают надежное выполнение асинхронных задач, встроенную панель мониторинга, поддержку повторяющихся или запланированных заданий, а также сохранение заданий в базе данных.

Обработка с помощью транзакционного Outbox

Чтобы обеспечить согласованность асинхронной интеграции, Lino использует транзакционный шаблон Outbox. Вариант использования в бизнесе сохраняет изменения домена и записывает событие интеграции в таблицу Outbox в рамках одной транзакции. Затем Background Job считывает таблицу Outbox и публикует событие через настроенную шину сообщений, например RabbitMQ, с MassTransit, если для проекта выбраны эти параметры.

1. Команда изменяет состояние домена и сохраняет это изменение в транзакции.
2. Обработчик регистрирует событие интеграции в Outbox, например событие, связанное с созданием заказа.
3. Задание Hangfire блокирует пакет необработанных сообщений и помечает эти сообщения как находящиеся в обработке.
4. Каждое сообщение десериализуется и публикуется шиной событий.
5. Успешные сообщения помечаются как обработанные; Сообщения об ошибках сохраняют информацию об ошибках для последующего анализа или стратегии повторных попыток.

Результатом является атомарность между базой данных и записанными событиями, надежность, позволяющая не терять события в случае сбоя, и масштабируемость, позволяющая нескольким потребителям обрабатывать опубликованные сообщения.

Сгенерированное задание также включает в себя процедуры удаления старых сообщений Outbox, которые уже были успешно обработаны, и освобождения сообщений, которые застряли в обработке, что снижает риск постоянных блокировок после сбоев приложений.

Если установлена ​​проверка подлинности, функция фонового задания также может выполнять задания по обслуживанию токенов, сохраняя данные безопасности в чистоте с течением времени.

Благодаря этим дополнительным функциям Lino обеспечивает надежную безопасность, детальный контроль доступа и надежную асинхронную обработку для критически важных требований современных производственных приложений.

Multi-tenancy

Multi-tenancy — это функция, используемая, когда одному и тому же приложению необходимо обслуживать несколько клиентов, организаций или сред, сохраняя при этом изолированные данные, разрешения и конфигурации для каждого tenantа. В Lino добавлена ​​поддержка tenantов:

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

Эту команду также можно выполнить в интерактивном режиме с помощью lino feature tenant add. Ветка CLI также предоставляет псевдонимы, такие как tenancy.

Предварительные условия

Поддержка tenantов зависит от двух архитектурных возможностей:

• Аутентификация и авторизация, поскольку доступ пользователей, роли, разрешения и токены должны учитывать интересы tenantов.
• Обмен сообщениями, поскольку информация о клиенте и пользователе может передаваться в другие модули посредством событий интеграции.

Если эти предварительные условия отсутствуют, команда отклоняется. Эту функцию также можно установить только один раз для каждого проекта.

Что генерируется

Lino создает модель tenancy, конфигурацию, события, интеграцию с API и frontend-ресурсы, необходимые для последовательного управления tenants.

• Tenant хранит идентификатор tenantа, имя, slug, статус, режим изоляции и ссылку на строку подключения.
• TenantBranding хранит данные брендинга для конкретного визуального поведения каждого tenantа.
• TenantDomain сопоставляет хосты или домены tenantам.
• TenantStatus и IsolationMode определить жизненный цикл tenantа и варианты изоляции данных.
• Сгенерированная конфигурация поддерживает разрешение tenantов и изоляцию данных проекта.

Безопасность с учетом tenantов

Аренда меняет способ интерпретации аутентификации и авторизации. Действительный токен и разрешение оцениваются в контексте текущего клиента; пользователь, имеющий доступ в одном tenantе, не получает автоматически доступ к другому tenantу. Таким образом, клиент поддерживает обновления потоков проверки подлинности, поведения токена обновления, разрешений и ссылок, созданных для пользовательского интерфейса.

В созданные приложения Blazor можно добавить экраны с поддержкой tenantов для управления tenantами и потоками авторизации. На внутренней стороне сгенерированные endpoints могут определять контекст клиента на основе настроенного поведения хоста, сегмента или маршрута, а затем применять идентификатор клиента в данных и решениях по авторизации.

Изоляция и распространение данных

Lino поддерживает моделирование домена с учетом tenantов, позволяя объектам объявлять право собственности для каждого tenantа. В сценариях SaaS это позволяет бизнес-таблицам хранить данные, относящиеся к tenantу, в то время как общие модули продолжают получать необходимую им информацию о клиенте и пользователе.

Сгенерированная архитектура использует события и шаблон Outbox для распространения выбранных данных tenantа или пользователя между модулями без привязки всех модулей напрямую к исходным таблицам Identity или Tenancy. Это сохраняет границы модуля четкими, в то время как экраны, API, разрешения и запросы продолжают работать с контекстом клиента.

После добавления tenancy создайте и примените migrations для затронутого сервиса, проверьте сгенерированные secrets и API keys, запустите AppHost и проверьте как минимум два tenants, чтобы гарантировать, что данные, пользователи, roles, permissions и бизнес-записи остаются изолированными.

• Подтвердите изоляцию: создавать тесты, пытающиеся получить доступ к данным от другого tenantа.
• Разрешения на просмотр: пользователь может иметь разные роли в разных tenantах.
• Не доверяйте клиенту: Клиент, которому сообщается маршрут, хост, пул или заголовок, должен быть совместим с аутентифицированным пользователем.