Hinzufügen von Features

Authentifizierung und Autorisierung

Die Authentifizierungsfunktion fügt die Sicherheitsgrundlage hinzu, die von Lino-Projekten verwendet wird, um APIs zu schützen, Benutzer zu identifizieren, den Zugriff auf Vorgänge zu kontrollieren und dieselben Berechtigungen in Blazor-Web-Apps zu integrieren. Die Installation erfolgt mit dem Befehl:

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

Der Befehl kann auch interaktiv mit ausgeführt werden lino feature auth add. Der kanonische Zweig ist feature auth; CLI macht auch Aliase verfügbar wie feature security und feature identity.

In der aktuellen Lino-Architektur basieren Authentifizierung und Autorisierung auf asynchronem Messaging. Der Grund ist betrieblicher Natur: Dienst- und Modulberechtigungen werden durch Integrationsereignisse synchronisiert, daher muss für das Projekt Messaging aktiviert sein, bevor Sicherheit hinzugefügt werden kann.

Was der Zauberer verlangt

CLI validiert das aktuelle Projekt, prüft, ob die Funktion noch nicht installiert wurde, fragt, wo das Sicherheitsmodul erstellt werden soll und fordert die wichtigsten Token-Einstellungen an.

• Service: Dienst, der die Sicherheitsressourcen hostet.
• Modul: Zielmodul, wenn der ausgewählte Dienst modular ist.
• Lebensdauer des Zugriffstokens: Lebensdauer der ausgestellten Zugriffstoken in Minuten.
• Lebensdauer des Aktualisierungstokens: Lebensdauer der Token, die zur Erneuerung von Sitzungen verwendet werden.
• Benutzer-ID-Typ: Art der Daten, die als Benutzerkennung verwendet werden, z int, long oder Guid.

Generiertes Sicherheitsmodell

Nach der Bestätigung aktualisiert Lino Projektmetadaten, erstellt Sicherheitskonfigurationswerte, generiert Quellcodedateien und führt erforderliche Befehle aus. Das generierte Modell umfasst die zentralen Sicherheitseinheiten:

• User speichert Identitaeten und Profildaten.
• Role und Rollenzuordnungen zu Gruppenzugriffsregeln.
• Permission und Beziehungen zwischen Rollen und Berechtigungen für eine detaillierte Autorisierung.
• UserToken zur Steuerung von Aktualisierungstoken und Token-Lebenszyklus.

Die Funktion erstellt auch die Informationen, die fuer die Sicherheitskonfiguration benoetigt werden, z. B. das Geheimnis zum Signieren von Tokens sowie die Lebensdauer von Access Tokens und Refresh Tokens. Sensible Werte werden als Befehle an AppHost-Benutzergeheimnisse ausgegeben, anstatt direkt in versionierte Dateien geschrieben zu werden.

Laufzeitverhalten

Die API verwendet JWT-Bearer-Authentifizierung. Der Benutzer meldet sich an, erhält ein Access Token und ein Refresh Token und sendet Anfragen an die API mit dem Header Authorization: Bearer <token>. Das Backend validiert das Token, lädt den Benutzerkontext und wendet Autorisierungsregeln auf die Endpunkte an.

Der typische Ablauf bleibt einfach: Anmeldung über Endpunkt oder dedizierte Seite, Ausstellen von JWT mit Identitätsansprüchen, Rollen und Berechtigungen, Senden des Tokens in jeder Anfrage und Validieren der Signatur und des Ablaufs durch die Authentifizierungs-Middleware.

Lino verwendet Richtlinien und Berechtigungen, um eine detaillierte Autorisierung zu implementieren. Für jede Aktion ist möglicherweise eine bestimmte Erlaubnis erforderlich, z People.Read oder People.Create; Richtlinien können über konfiguriert werden AddAuthorization; und Endpunkte können durch Deklaration geschützt werden .RequireAuthorization.

Generierte Endpunkte und Seiten verwenden Berechtigungen konsistent. Für Backend-Vorgänge sind möglicherweise Berechtigungen erforderlich, während die generierte Blazor-Benutzeroberfläche Berechtigungen laden, Seiten schützen, nicht verfügbare Aktionen ausblenden und Bildschirme für Benutzer, Rollen, Berechtigungen und Autorisierungen anzeigen kann, wenn im Projekt eine Web-App vorhanden ist.

Wenn Background Jobs bereits aktiviert sind, fügt Lino auch Jobs hinzu, die sich auf Benutzertokens beziehen, z. B. Wartungsroutinen für deaktivierte oder abgelaufene Token.

Background processing und Outbox

Die Background processing erledigt Arbeiten, die den Hauptanforderungs- und Antwortfluss nicht blockieren sollten: Veröffentlichen von Integrationsereignissen, Bereinigen alter Datensätze, Entfernen abgelaufener Token, Senden von Benachrichtigungen, Generieren von Berichten, Synchronisieren mit externen Systemen oder Ausführen geplanter Aufgaben. Lino fügt diese Funktion über die Background Jobfunktion hinzu:

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

Der Befehl kann auch als ausgeführt werden lino feature background-job add und interaktiv bearbeitet werden. CLI macht Aliase verfügbar als job-scheduler und worker.

Diese Funktion erfordert die Aktivierung von Messaging im Projekt, da ihre Hauptaufgabe darin besteht, Messaging sicher zu veröffentlichen, die durch den Transactional Outbox-Standard registriert sind.

Was der Zauberer verlangt

• Service: Dienst, in dem die Infrastruktur für Background Jobs installiert wird.
• Background Jobbibliothek: Implementierung, die zum Ausführen und Planen von Jobs verwendet wird. Die aktuell generierte Infrastruktur verwendet Hangfire.
• Outbox Verarbeitung: Definiert, ob der Dienst Ereignisse registriert, die vom Scheduler verarbeitet werden sollen.
• Outbox-Zeitplan: Bereich oder Zeitplanausdruck, der zur Prüfung auf neue Messaging verwendet wird Outbox.
• Outbox-Batchgroesse: Anzahl der pro Zyklus abgerufenen und verarbeiteten Outbox-Datensätze zur Steuerung von Last, Parallelität und Ressourcenverbrauch.

Hangfire Infrastruktur

Lino generiert die erforderliche Infrastruktur, um Hangfire zu registrieren, seine Persistenz zu konfigurieren, das Dashboard verfügbar zu machen und die vom Dienst verwendeten Jobs zu planen. Die generierte Konfiguration enthaelt die Informationen, die zum Planen von Jobs, zum Verarbeiten von Outbox-Nachrichten und zum Schuetzen des Scheduler-Dashboards erforderlich sind.

In generierten Lösungen sind das Hangfire-Schema und die Tabellen Teil der Anwendungsdatenbankkonfiguration. Das Dashboard hilft Ihnen, abgeschlossene, fehlgeschlagene, geplante und wiederkehrende Jobs während der Entwicklung und des Betriebs zu überprüfen.

Zu den praktischen Vorteilen gehören die zuverlässige Ausführung asynchroner Aufgaben, ein integriertes Überwachungs-Dashboard, die Unterstützung wiederkehrender oder geplanter Jobs sowie die Persistenz von Jobs in der Datenbank.

Verarbeitung mit transaktionalem Outbox

Um die Konsistenz bei asynchronen Integrationen sicherzustellen, verwendet Lino das Transaktionsmuster Outbox. Ein Geschäftsanwendungsfall speichert Domänenänderungen und zeichnet ein Integrationsereignis in der Tabelle Outbox innerhalb derselben Transaktion auf. Der Background Job liest dann die Tabelle Outbox und veröffentlicht das Ereignis über den konfigurierten Messagingbus, z. B. RabbitMQ mit MassTransit, wenn diese Optionen für das Projekt ausgewählt wurden.

1. Ein Befehl ändert den Zustand der Domäne und speichert diese Änderung in einer Transaktion.
2. Ein Handler registriert ein Integrationsereignis in Outbox, beispielsweise ein Ereignis im Zusammenhang mit der Erstellung einer Bestellung.
3. Der Auftrag Hangfire blockiert einen Stapel unverarbeiteter Messaging und markiert diese Messaging als in Bearbeitung.
4. Jede Nachricht wird deserialisiert und vom Ereignisbus veröffentlicht.
5. Erfolgreiche Messaging werden als verarbeitet markiert; Bei fehlgeschlagenen Messaging bleiben Fehlerinformationen für eine spätere Analyse oder Wiederholungsstrategie erhalten.

Das Ergebnis ist Atomizität zwischen der Datenbank und aufgezeichneten Ereignissen, Zuverlässigkeit, sodass Ereignisse im Fehlerfall nicht verloren gehen, und Skalierbarkeit, sodass mehrere Verbraucher veröffentlichte Messaging verarbeiten können.

Der generierte Job umfasst außerdem Routinen zum Entfernen alter Outbox-Messaging, die bereits erfolgreich verarbeitet wurden, und zum Freigeben von Messaging, die in der Verarbeitung hängengeblieben sind, wodurch das Risiko dauerhafter Sperren nach Anwendungsfehlern verringert wird.

Wenn die Authentifizierung installiert ist, kann die Background Jobfunktion auch Token-Wartungsjobs hosten und so die Sicherheitsdaten im Laufe der Zeit sauber halten.

Mit diesen zusätzlichen Features bietet Lino robuste Sicherheit, granulare Zugriffskontrolle und zuverlässige asynchrone Verarbeitung für kritische Anforderungen moderner Produktionsanwendungen.

Multi-tenancy

Multi-tenancy ist die Funktion, die verwendet wird, wenn dieselbe Anwendung mehrere Clients, Organisationen oder Umgebungen bedienen und gleichzeitig isolierte Daten, Berechtigungen und Konfigurationen für jeden Tenants beibehalten muss. In Lino wird Tenant-Unterstützung hinzugefügt mit:

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

Der Befehl kann auch interaktiv mit lino feature tenant add ausgeführt werden. Der CLI-Zweig stellt auch Aliase wie tenancy bereit.

Voraussetzungen

Die Tenant-Unterstützung hängt von zwei architektonischen Fähigkeiten ab:

• Authentifizierung und Autorisierung, da Benutzerzugriff, Rollen, Berechtigungen und Token mandantenbewusst sein müssen.
• Messaging, da Tenants- und Benutzerinformationen durch Integrationsereignisse an andere Module weitergegeben werden können.

Fehlen diese Voraussetzungen, wird der Befehl abgelehnt. Das Feature kann auch nur einmal pro Projekt installiert werden.

Was wird generiert

Lino erstellt das Tenantsmodell, die Konfiguration, Ereignisse, die API-Integration und die Frontend-Ressourcen, die für die konsistente Verwaltung von Tenants erforderlich sind.

• Tenant speichert die Identitaet des Tenants, den Namen, den Slug, den Status, den Isolationsmodus und die Connection-String-Referenz.
• TenantBranding speichert Branding-Daten für spezifisches visuelles Verhalten pro Tenant.
• TenantDomain ordnet Hosts oder Domänen Tenants zu.
• TenantStatus und IsolationMode definieren Tenantslebenszyklus- und Datenisolationsoptionen.
• Die generierte Konfiguration unterstuetzt die Tenant-Aufloesung und Datenisolierung im Projekt.

Tenantbewusste Sicherheit

Das Tenancy verändert die Art und Weise, wie Authentifizierung und Autorisierung interpretiert werden. Ein gültiges Token und eine gültige Berechtigung werden im Kontext des aktuellen Tenants ausgewertet; Ein Benutzer mit Zugriff auf einen Tenants erhält nicht automatisch Zugriff auf einen anderen Tenants. Daher aktualisiert die Tenant-Unterstützung Authentifizierungsabläufe, Aktualisierungstokenverhalten, Berechtigungen und Referenzen, die für die Benutzeroberfläche generiert werden.

In generierten Blazor-Anwendungen können mandantenbezogene Bildschirme zur Verwaltung von Tenants und Autorisierungsabläufen hinzugefügt werden. Im Backend können generierte Endpunkte den Tenantskontext anhand des konfigurierten Host-, Slug- oder Routenverhaltens auflösen und dann die Tenantskennung in Daten- und Autorisierungsentscheidungen anwenden.

Datenisolierung und -verbreitung

Lino unterstützt die mandantenbezogene Domänenmodellierung, indem es Entitäten ermöglicht, den Besitz pro Tenant anzugeben. In SaaS-Szenarien ermöglicht dies, dass Geschäftstabellen mandantenspezifische Daten speichern, während gemeinsam genutzte Module weiterhin die benötigten Tenants- und Benutzerinformationen erhalten.

Die generierte Architektur verwendet Ereignisse und das Outbox-Muster, um ausgewählte Tenants- oder Benutzerdaten zwischen Modulen weiterzugeben, ohne alle Module direkt an die ursprünglichen Identitäts- oder Tenantstabellen zu koppeln. Dadurch bleiben Modulgrenzen klar, während Bildschirme, APIs, Berechtigungen und Abfragen weiterhin mit dem Tenantskontext arbeiten.

Erstellen Sie nach dem Hinzufügen eines Tenants Migrationen für den betroffenen Dienst und wenden Sie diese an, überprüfen Sie generierte secrets und API-Schlüssel, führen Sie AppHost aus und validieren Sie mit mindestens zwei Tenants, um sicherzustellen, dass Daten, Benutzer, Rollen, Berechtigungen und Geschäftsdatensätze isoliert bleiben.

• Isolation validieren: Erstellen Sie Tests, die versuchen, auf Daten eines anderen Tenants zuzugreifen.
• Berechtigungen prüfen: Ein Benutzer kann in verschiedenen Tenants unterschiedliche Rollen haben.
• Vermeiden Sie es, dem Client zu vertrauen: Der über Route, Host, Slug oder Header informierte Tenant muss mit dem authentifizierten Benutzer kompatibel sein.