Konfiguration

Die Konfiguration des Babel Licensing Service ist ein wesentlicher Teil beim Aufbau einer sicheren und zuverlässigen Lizenzierungsinfrastruktur. Ein zentrales Element dieser Konfiguration ist die Datei appsettings.json, in der Sie verschiedene Parameter und Einstellungen für den Babel Licensing Service festlegen.

Die Konfigurationsdatei appsettings.json des Babel Licensing Service enthält verschiedene Einstellungen für die Anwendung. Die Abschnitte im Überblick:

1. Serilog: Dieser Abschnitt konfiguriert die Protokollierung mit der Bibliothek Serilog. Er legt die Senken (Sinks) für die Protokollierung fest (Konsole und Datei), die Protokollstufen für verschiedene Namespaces und die Enricher für zusätzliche Kontextinformationen.
2. AllowedHosts: Dient der Hostfilterung, um Ihre Anwendung an bestimmte Hostnamen zu binden.
3. Kestrel: Dieser Abschnitt konfiguriert die Einstellungen des Webservers Kestrel. Er definiert die Standardprotokolle und die Endpunkte für den gRPC-Dienst.
4. Application: Dieser Abschnitt enthält Einstellungen, die die Anwendung Babel Licensing Service selbst betreffen. Er legt fest, ob gRPC-Web eingeschaltet ist, wo die Lizenzdatei liegt, welcher Signaturschlüssel für die Lizenzvalidierung gilt und wie lange ein Token gültig ist.
5. Email: Diese Einstellungen konfigurieren die E-Mail-Benachrichtigungen. Dazu gehören das Ein- und Ausschalten des E-Mail-Versands, die Angaben zum SMTP-Server (Host, Port, SSL), die Anmeldedaten und die Angaben zu Absender und Empfängern.
6. Licensing: Dieser Abschnitt konfiguriert verschiedene Aspekte des Lizenzierungssystems. Er legt das Lebenszeichen-Intervall und die Tokenformate für Aktivierungs- und Floating-Lizenzen fest.
7. Reporting: Dieser Abschnitt konfiguriert den Reporting-Dienst und enthält den Verschlüsselungsschlüssel, der bei der Erzeugung von Berichten verwendet wird.
8. Database: Dieser Abschnitt legt den Datenbankanbieter fest, den die Anwendung verwendet.
9. ConnectionStrings: Diese Einstellungen definieren die Verbindungszeichenfolgen für die verschiedenen Datenbankanbieter (SQL Server, MySQL/MariaDB, SQLite, PostgreSQL).

Jeder Abschnitt lässt sich an die Anforderungen der jeweiligen Bereitstellung des Babel Licensing Service anpassen.

Serilog

Serilog übernimmt die Protokollierung im Babel Licensing Service. Sehen wir uns an, wie die Serilog-Konfiguration in der Datei appsettings.json aufgebaut ist.

"Serilog": {
  "Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File" ],
  "MinimumLevel": {
    "Default": "Information",
    "Override": {
      "Microsoft": "Warning",
      "System": "Warning",
      "Grpc": "Warning"
    }
  },
  "Enrich": [
    "FromLogContext",
    "WithMachineName",
    "WithThreadId"
  ],
  "WriteTo": [
    { "Name": "Console" },
    {
      "Name": "File",
      "Args": {
        "path": "log.txt",
        "rollingInterval": "Day"
      }
    }
  ]
}

Zuerst definieren wir den Abschnitt "Serilog", der mehrere wichtige Elemente enthält.

Using: Diese Eigenschaft gibt die Serilog-Senken an, die für die Protokollierung verwendet werden. In diesem Beispiel sind das "Serilog.Sinks.Console" und "Serilog.Sinks.File", die Protokolle werden also sowohl in die Konsole als auch in eine Datei geschrieben.

MinimumLevel: Legt die minimale Protokollstufe für verschiedene Protokollquellen fest. Der Wert Default ist auf „Information“ gesetzt, sodass alle Protokolle der Stufe Information oder höher aufgezeichnet werden. Zusätzlich gibt es einen Abschnitt Override, der für bestimmte Namespaces eigene Protokollstufen festlegt. Die verfügbaren Protokollstufen sind:

• Verbose: Verbose ist die ausführlichste Stufe und wird in der Produktion selten (wenn überhaupt) eingeschaltet.
• Debug: Debug wird für interne Systemereignisse verwendet, die von außen nicht unbedingt sichtbar sind, aber helfen zu klären, wie etwas abgelaufen ist
• Information: Information-Ereignisse beschreiben Vorgänge im System, die seinen Aufgaben und Funktionen entsprechen. Die Stufe wird im Allgemeinen verwendet, um gRPC-Aufrufe zu protokollieren.
• Warning: Ereignisse der Stufe Warning werden verwendet, wenn der Dienst beeinträchtigt oder gefährdet ist oder sich möglicherweise außerhalb der erwarteten Parameter verhält.
• Error: Ein Error-Ereignis wird verwendet, wenn eine Funktion nicht verfügbar ist oder Erwartungen nicht erfüllt werden.
• Fatal: Die kritischste Stufe: Fatal-Ereignisse erfordern sofortige Aufmerksamkeit.

Enrich: Mit dieser Eigenschaft werden Protokollereignisse um zusätzliche Informationen angereichert. In diesem Beispiel werden sie um Informationen wie den Protokollkontext, den Rechnernamen und die Thread-ID ergänzt.

WriteTo: Die Eigenschaft WriteTo legt die Senken fest, in die die Protokollereignisse geschrieben werden. Konfiguriert sind zwei Senken: „Console“ und „File“. Die Senke „Console“ schreibt die Protokollereignisse in die Konsole. Bei der Senke „File“ ist die Eigenschaft „path“ auf „log.txt“ gesetzt, die Protokollereignisse werden also in eine Datei namens log.txt geschrieben. Außerdem ist „rollingInterval“ auf „Day“ gesetzt, sodass jeden Tag eine neue Protokolldatei angelegt wird.

Für speziellere Einstellungen und erweiterte Konfigurationen zu Filterung, Sub-Loggern und weiteren Funktionen von Serilog empfiehlt sich die offizielle Serilog-Dokumentation. Sie beschreibt die Konfigurationsoptionen ausführlich, darunter das Filtern und Anreichern von Protokollereignissen und die Konfiguration von Sub-Loggern.

AllowedHosts

Die Konfiguration „AllowedHosts“ in der Datei appsettings.json legt die Hostfilterung für den Babel Licensing Service fest. Sie ist eine wichtige Sicherheitsmaßnahme, die den Zugriff auf den Dienst auf vertrauenswürdige URLs beschränkt. Der Wert „*“ bedeutet, dass die Hostfilterung ausgeschaltet ist und jede URL, die an den Host gebunden ist, auf den Dienst zugreifen kann. Das kann für Entwicklungs- oder Testumgebungen angemessen sein. In der Produktion empfiehlt es sich dagegen, die Hosts ausdrücklich anzugeben.

Einige Beispiele dafür, wie Sie die Einstellung „AllowedHosts“ konfigurieren können:

1. Einen bestimmten Host zulassen:

   "AllowedHosts": "example.com"

   Diese Konfiguration beschränkt den Zugriff auf den Babel Licensing Service auf Anfragen an die Domäne „example.com“. Alle Anfragen an andere Hosts erhalten eine Antwort 400 mit dem Hinweis, dass der Hostname ungültig ist.

2. Mehrere Hosts zulassen:

   "AllowedHosts": "example.com;subdomain.example.com"

   Diese Konfiguration lässt den Zugriff auf den Babel Licensing Service nur von „example.com“ und „subdomain.example.com“ zu. Anfragen von jeder anderen Domäne werden abgelehnt.

3. Mehrere Hosts mit einem Platzhalterausdruck zulassen:

   "AllowedHosts": "*.example.com"

   Diese Konfiguration lässt den Zugriff auf den Babel Licensing Service von jeder Subdomäne von „example.com“ zu. So werden zum Beispiel „subdomain.example.com“ und „another.subdomain.example.com“ zugelassen, Anfragen von anderen Domänen oder Subdomänen dagegen zurückgewiesen.

Es ist wichtig, die Einstellung „AllowedHosts“ sorgfältig abzuwägen und passend zu Ihrer Bereitstellungsumgebung und Ihren Sicherheitsanforderungen zu konfigurieren. Indem Sie den Zugriff auf vertrauenswürdige Hosts beschränken, erhöhen Sie die Sicherheit und Integrität Ihres Babel Licensing Service.

Kestrel

Der Konfigurationsabschnitt „Kestrel“ in der Datei appsettings.json konfiguriert den Webserver Kestrel, der den Babel Licensing Service hostet. Kestrel ist ein plattformübergreifender Webserver, der eine schnelle und zuverlässige Hostingumgebung für Ihre Anwendung bietet.

"Kestrel": {
  "EndpointDefaults": {
    "Protocols": "Http1AndHttp2"
  },
  "Endpoints": {
    "gRPC": {
      "Url": "http://localhost:5005",
      "Protocols": "Http2"
    }
  }
}

Im Abschnitt „Kestrel“ können Sie verschiedene Einstellungen festlegen, um das Verhalten des Servers anzupassen. Sehen wir uns einige wichtige Elemente der Kestrel-Konfiguration an:

EndpointDefaults: In diesem Unterabschnitt legen Sie Standardkonfigurationen für alle Endpunkte fest. Hier können Sie die Protokolle angeben, die der Server unterstützt. Im gezeigten Beispiel bedeutet „Http1AndHttp2“, dass die Protokolle HTTP/1.1 und HTTP/2 standardmäßig beide eingeschaltet sind.

Endpoints: In diesem Unterabschnitt definieren Sie einzelne Endpunkte für den Server. Im Beispiel ist der Endpunkt „gRPC“ mit der URL „http://localhost:5005“  und dem Protokoll „Http2“ konfiguriert. Dieser Endpunkt ist eigens dafür vorgesehen, gRPC-Anfragen zu verarbeiten, die über das Protokoll HTTP/2 an den Babel Licensing Service gestellt werden.

Eine korrekte Konfiguration von Kestrel ist wesentlich für den reibungslosen Betrieb Ihres Babel Licensing Service. Sie können Aspekte wie Protokolle, Portnummern, SSL-Zertifikate und mehr an Ihre Anforderungen anpassen.

Halten Sie sich bei der Konfiguration von Kestrel an die offizielle Dokumentation und an bewährte Vorgehensweisen, um optimale Leistung, Sicherheit und Zuverlässigkeit zu erreichen.

Application

Im Konfigurationsabschnitt „Application“ der appsettings.json passen Sie verschiedene Aspekte des Babel Licensing Service an. Sehen wir uns die einzelnen Einstellungen genauer an:

"Application": {
    "AdminUsername": "",
    "AdminEmail": "",
    "AdminPassword": "",
    "EnableLegacyUserKeyFallback": false,
    "EnableGrpcWeb": true,
    "LogToDatabase": false,
    "LogRetentionPeriod": "1.00:00:00",
    "LicenseFile": "babel.licenses",
    "SigningKey": "",
    "TokenExpiration": "00:30:00",
    "EnableWebApi": true,
    "EnableWebUI": true,
    "ApiKeyHeaderName": "x-api-key",
    "ApiKeyCacheDuration": "00:03:00",
    "EnableSwagger": true,
    "SwaggerRoutePrefix": "swagger",
    "SwaggerEndpointUrl": "/swagger/v1/swagger.json",
    "GeoLocationService": "IpApiIs",
    "HealthCheckEndPoint": "/health",
    "HealthCheckResponseType": "JSON"
}

AdminUsername: Zusammen mit AdminEmail und AdminPassword sind dies die Anmeldedaten, mit denen beim ersten Start des Dienstes der erste administrative Benutzer angelegt wird.

Ab Version 11.7.0 wird der Dienst mit drei leeren Werten ausgeliefert: Der frühere Standard admin / admin wurde entfernt. Der erste Administrator wird nur angelegt, wenn sowohl AdminUsername als auch AdminPassword nicht leer sind (AdminEmail ist optional, wird aber empfohlen). Ist einer der beiden erforderlichen Werte leer, startet der Dienst trotzdem und legt die Standardrollen an. Es wird jedoch kein Administratorkonto erstellt, und die Webanwendung lässt sich erst verwenden, wenn Sie die Einstellungen ausfüllen und den Dienst neu starten. Verwenden Sie entweder appsettings.json oder die Umgebungsvariablen BABEL_SERVICE_APPLICATION__ADMINUSERNAME / ..._ADMINPASSWORD / ..._ADMINEMAIL. Ändern Sie anschließend das Passwort über die Webanwendung und entfernen Sie AdminPassword aus der Konfiguration, sobald das Konto existiert.

LogToDatabase: Legt fest, ob Protokolle in einer Datenbank gespeichert werden.

LogRetentionPeriod: Gibt an, wie lange Protokolle aufbewahrt werden, im Format Tage.Stunden:Minuten:Sekunden.

EnableGrpcWeb: Wenn Sie diesen Wert auf false setzen, schalten Sie die Unterstützung für gRPC Web aus. Der Server nimmt dann nur Anfragen über das Protokoll HTTP/2 an. Beachten Sie, dass manche Clientplattformen wie UWP oder Unity HTTP/2 möglicherweise nicht unterstützen. HTTP/1.1 neben HTTP/2 einzuschalten stellt daher die Kompatibilität mit allen Clientanwendungen sicher. Bedenken Sie, dass beide Protokolle auf demselben Port TLS für die Protokollaushandlung erfordern.

LicenseFile: Diese Einstellung gibt den Pfad zur Lizenzdatei an, die der Babel Licensing Service verwendet. Die Lizenzdatei enthält Informationen über die gewährten Lizenzen und die zugehörigen Funktionen. Die Lizenz bestimmt auch die Edition: Eine Lizenz mit der Funktion für die Webanwendung (Data Center) schaltet die im Paket enthaltene Webanwendung frei. Bei anderen Lizenzen erscheint unter der Adresse der Webanwendung eine Upgrade-Seite. Für ein Upgrade genügt es, die Datei zu ersetzen und den Dienst neu zu starten.

SigningKey: Der Signaturschlüssel ist ein Geheimnis, mit dem das Bearer-Token für die Authentifizierung signiert wird. Mit diesem Token greifen Clients sicher auf den gRPC-Dienst zu. Es ist unerlässlich, diesen Schlüssel vertraulich zu halten und einen starken, eindeutigen Wert zu wählen.

Ab Version 11.7.0 wird diese Einstellung leer ausgeliefert (der frühere fest codierte Wert wurde entfernt). Ist SigningKey beim Start leer, erzeugt der Dienst für den laufenden Prozess einen kryptografisch zufälligen Schlüssel von 32 Byte und protokolliert eine Warnung. Das ist für lokale Tests bequem, aber nicht für die Produktion geeignet: Jeder Neustart macht alle zuvor ausgestellten Token ungültig, und Instanzen hinter einem Load Balancer lehnen die Token der jeweils anderen ab. In Produktionsbereitstellungen muss SigningKey ausdrücklich konfiguriert werden, entweder in appsettings.json oder über die Umgebungsvariable BABEL_SERVICE_APPLICATION__SIGNINGKEY, und zwar mit einem starken Geheimnis, das außerhalb der Quellcodeverwaltung verwaltet wird.

SigningKey immer konfigurieren: In aktuellen Builds (bis einschließlich 11.8.0) hat ein leerer SigningKey weitere Folgen als ungültige Token nach einem Neustart: Das nach der Authentifizierung ausgestellte Token wird bei den folgenden Aufrufen nicht akzeptiert, sodass die Lizenzaktivierung fehlschlägt mit:

RpcException: Status(StatusCode="Unauthenticated", Detail="Bad gRPC response. HTTP status code: 401")

Das Protokoll des Dienstes zeigt unmittelbar vor dem 401 eine erfolgreiche Authentifizierung (User '' authenticated, token expires in ...), wodurch der Fehler wie ein Problem des Clients aussieht. Abhilfe schafft es, SigningKey auf einen beliebigen stabilen, nicht leeren Wert mit mindestens 32 Zeichen zu setzen. Das wird in einer künftigen Version behoben. Den Schlüssel ausdrücklich zu konfigurieren ist in jedem Fall die richtige Einstellung für die Produktion.

EnableLegacyUserKeyFallback: Stellt die Authentifizierungskompatibilität für Clientanwendungen wieder her, die mit einem NuGet-Paket Babel.Licensing erstellt wurden, das älter ist als die Version mit der Korrektur für das unten beschriebene Problem der Authentifizierung mit Benutzerschlüssel über gRPC. Der Standardwert ist false.

Authentifizierung mit Benutzerschlüssel über gRPC: Clientanwendungen, die mit Versionen von Babel.Licensing vor der Korrektur erstellt wurden, senden bei der Authentifizierung mit dem Benutzerschlüssel (UserKey) einer Lizenz als Benutzernamen eine interne Clientkennung statt eines leeren Werts. Vor 11.7.0 wurde das durch einen serverseitigen Fallback stillschweigend toleriert. Die Sicherheitshärtung in 11.7.0 hat diesen Fallback entfernt (siehe Client-Komponenten). Seitdem schlägt jede Authentifizierung mit Benutzerschlüssel über gRPC von einem betroffenen Client fehl, bei bestehenden wie bei neu erzeugten Schlüsseln, und zwar mit „Invalid username or password“. Aktualisieren Sie auf das aktuelle Paket Babel.Licensing, um das Problem an der Ursache zu beheben. Wenn Sie viele Clientanwendungen im Einsatz haben und nicht alle sofort aktualisieren können, setzen Sie EnableLegacyUserKeyFallback als vorübergehende Migrationshilfe auf true: Der Dienst akzeptiert dann die fehlerhafte Anfrage wieder und stellt dasselbe Anwendungstoken ohne Rollen aus, das ein betroffener Client sonst erhielte (es gewährt keine Rollen und erreicht keine Management-Endpunkte, hat also nicht mehr Rechte als die normale Authentifizierung mit Benutzerschlüssel). Setzen Sie den Wert wieder auf false, sobald alle Clients aktualisiert sind. Bei jeder Verwendung des Fallbacks protokolliert der Dienst eine Warnung mit dem betreffenden Benutzernamen, damit Sie die verbliebenen alten Clients ermitteln können.

TokenExpiration: Diese Einstellung bestimmt die Gültigkeitsdauer des Bearer-Tokens, das der Client bei der Authentifizierung erhält. Der Wert „00:30:00“ bedeutet eine Gültigkeit von 30 Minuten. Danach muss der Client ein neues Token anfordern, um weiter Zugriff zu haben.

EnableWebApi: Legt fest, ob die Web-API eingeschaltet wird.

EnableWebUI: Legt fest, ob der Dienst die Webanwendung bereitstellt. Setzen Sie den Wert auf false, um den Dienst nur als API zu betreiben. Die Webanwendung erfordert außerdem eine Data-Center-Lizenz.

ApiKeyHeaderName: Bestimmt den Namen des HTTP-Headers, in dem der API-Schlüssel übergeben wird.

ApiKeyCacheDuration: Legt fest, wie lange ein API-Schlüssel im Cache bleibt, bevor er erneut validiert wird.

EnableSwagger: Schaltet die Swagger UI für die API-Dokumentation ein oder aus.

SwaggerRoutePrefix: Das URL-Segment, unter dem die Swagger UI erreichbar ist.

SwaggerEndpointUrl: Der Pfad zur Swagger-JSON-Datei, die die API beschreibt.

GeolocationService: Schaltet die Funktion ein, die den geografischen Standort von Clients anhand ihrer IP-Adressen ermittelt und so die regionale Zugriffssteuerung unterstützt. Unterstützt werden IpApiIs und MaxMind.

HealthCheckEndPoint: Konfiguriert den Pfad des Endpunkts für die Zustandsprüfung. Der Endpunkt der Zustandsprüfung liefert Statusinformationen des Systems für Überwachungstools und Load Balancer. Ohne ausdrückliche Konfiguration verwendet das System standardmäßig „/health“.

HealthCheckResponseType: Steuert das Format der Antworten, die der Endpunkt der Zustandsprüfung des Babel Licensing Service zurückgibt. Die Einstellung akzeptiert zwei Werte: „JSON“ oder „TEXT“.

Mit den Einstellungen im Abschnitt „Application“ passen Sie das Verhalten des Babel Licensing Service an Ihre Anforderungen an: Sie schalten die Unterstützung bestimmter Protokolle ein oder aus, geben den Pfad der Lizenzdatei an, sichern die Authentifizierung mit einem Signaturschlüssel und legen die Gültigkeitsdauer der Token fest.

IpApi.is

Der Dienst IpApi.is ermöglicht die Geolokalisierung: Er ermittelt anhand der IP-Adressen den geografischen Standort der Benutzer, was für die regionale Zugriffssteuerung, die Protokollierung und Auswertungen entscheidend sein kann. Er bietet einen schnellen und zuverlässigen Weg, IP-Adressen den zugehörigen geografischen Daten zuzuordnen.

Weitere Informationen finden Sie bei IpApi.is .

Um den Dienst IpApiIs mit dem Babel Licensing Service zu konfigurieren, gehen Sie so vor:

1. Setzen Sie im Abschnitt Application die Eigenschaft GeolocationService auf IpApiIs.
2. Fügen Sie der appsettings.json den Abschnitt IpApiIs hinzu, um den Zugriff auf den Dienst über einen Lizenzschlüssel zu konfigurieren.

"IpApiIs": {
  "Key": "IPAPI.IS WEB API SERVICE LICENSE KEY"
}

MaxMind

MaxMind bietet einen robusten Geolokalisierungsdienst, der sowohl den Zugriff über eine Web-API als auch die Nutzung einer lokalen Datenbank unterstützt. Mit der Integration von MaxMind nutzen Sie dessen hohe Genauigkeit bei Geolokalisierungsdaten. Der Dienst, verfügbar unter MaxMind , ermöglicht einen schnellen und zuverlässigen Abruf von Informationen zu IP-Adressen.

Ein Vorteil der lokalen Datenbank von MaxMind ist, dass die Abhängigkeit von externen API-Aufrufen entfällt. Das führt zu schnelleren Abfragen und höherer Zuverlässigkeit, vor allem in Umgebungen mit eingeschränkter oder instabiler Internetverbindung. Außerdem verringern lokale Datenbanken die Risiken durch Datenlecks oder Ausfälle externer Dienste und bieten mehr Kontrolle über Sicherheit und Datenschutz.

Um den Geolokalisierungsdienst MaxMind mit dem Babel Licensing Service zu konfigurieren, gehen Sie so vor:

1. Setzen Sie im Abschnitt Application die Eigenschaft GeolocationService auf MaxMind.
2. Fügen Sie der appsettings.json den Abschnitt MaxMind mit den erforderlichen Konfigurationsoptionen hinzu.

"MaxMind": {
  "AccountID": "MAXMIND ACCOUNT ID",
  "LicenseKey": "MAXMIND WEB API SERVICE LICENSE KEY"
}

Um die MaxMind-Datenbank zu konfigurieren, verwenden Sie die folgende Konfiguration:

"MaxMind": {
  "DatabasePath": "wwwroot\\data\\GeoLite2-City.mmdb"
}

Mit dieser Einrichtung verwendet der Babel Licensing Service MaxMind für die Geolokalisierung und erhält genaue und zuverlässige Informationen zu IP-Adressen.

IP-Filterung

Die IP-Filterung in den Anwendungseinstellungen ist eine Sicherheitsmaßnahme, die den Zugriff auf den Dienst anhand von IP-Adressen steuert. Dieser Abschnitt der Konfiguration sorgt dafür, dass nur vertrauenswürdige Benutzer mit Ihrer Anwendung interagieren können, während bösartiger oder unerwünschter Datenverkehr wirksam behandelt oder blockiert wird.

Die Konfiguration im Einzelnen:

Blacklist: Ein Array von IP-Adressen, denen der Zugriff verweigert wird. IP-Adressen auf der Sperrliste werden immer mit 403 Forbidden abgewiesen, unabhängig von allen anderen Einstellungen.

Whitelist: Ein Array vertrauenswürdiger IP-Adressen, die von der Begrenzung der Anfragerate des Brute-Force-Schutzes ausgenommen sind. Für IP-Adressen auf der Zulassungsliste gelten weder das Anfragekontingent pro IP-Adresse noch die dynamische Sperrung. Die Sperrliste gilt für sie weiterhin.

Verhaltensänderung in 11.7.0: Frühere Versionen behandelten eine nicht leere Whitelist als exklusive Zulassungsliste: Jede IP-Adresse, die nicht in der Liste stand, wurde abgewiesen. Ab 11.7.0 ist die Zulassungsliste ausschließlich eine Ausnahme von der Begrenzung der Anfragerate: Sie zu konfigurieren hindert nicht aufgeführte IP-Adressen nicht mehr am Zugriff auf den Dienst. Wenn Sie IP-Adressen sperren müssen, tragen Sie sie in die Blacklist ein (Regex-Muster werden unterstützt).

Beide Listen unterstützen den Musterabgleich mit regulären Ausdrücken, was die Möglichkeiten der IP-Filterung erweitert.

Brute-Force-Schutz

Dieser Unterabschnitt konfiguriert Gegenmaßnahmen gegen Brute-Force-Angriffe:

Enabled: Ein boolescher Wert, der bei true den Schutz vor Brute-Force-Angriffen einschaltet.

MaxRequestsPerTimeFrame: Die maximale Anzahl von Anfragen, die von einer einzelnen IP-Adresse innerhalb des angegebenen Zeitfensters zulässig ist.

TimeFrameDuration: Der Zeitraum, in dem die Anzahl der Anfragen ausgewertet wird, im Format Stunden:Minuten:Sekunden.

RequestsBlockDuration: Die Zeit, für die die betreffende IP-Adresse gesperrt wird, nachdem sie die maximale Anzahl von Anfragen überschritten hat.

Authentifizierungsschutz

Dieser Unterabschnitt betrifft Anmeldeversuche:

Enabled: Bei true wird die Überwachung fehlgeschlagener Authentifizierungsversuche eingeschaltet.

MaxFailedAttempts: Die zulässige Anzahl aufeinanderfolgender fehlgeschlagener Anmeldeversuche, bevor eine Sperre ausgelöst wird.

LoginBlockDuration: Die Dauer der Sperre, die für die IP-Adresse gilt, nachdem die maximale Anzahl fehlgeschlagener Anmeldeversuche erreicht wurde.

Webhook

Die Webhook-Einstellungen legen fest, ob Webhooks verarbeitet werden, wie oft das System nach neuen Ereignissen sucht und wie erneute Versuche geplant werden.

"Webhook": {
  "Enabled": true,
  "ProcessingInterval": "00:00:30",
  "RetryInterval": "00:05:00"
}

• Processing Interval: Das Standardintervall von 30 Sekunden passt für die meisten Bereitstellungen. Ein zu niedriger Wert kann die Datenbanklast erhöhen, ein zu hoher Wert kann die Zustellung der Webhooks verzögern.
• Retry Interval: Das Intervall von 5 Minuten für erneute Versuche lässt vorübergehenden Netzwerkproblemen Zeit, sich zu lösen, und stellt dennoch eine zeitnahe Zustellung sicher. Erwägen Sie einen höheren Wert, wenn die Empfänger Ihrer Webhooks häufig längere Ausfälle haben.
• Ein- und Ausschalten: Sie können die gesamte Webhook-Verarbeitung vorübergehend ausschalten, indem Sie Enabled auf false setzen. Das kann während Wartungsfenstern oder bei der Fehlerbehebung im System nützlich sein.

Email

Der Abschnitt „Email“ der Datei appsettings.json konfiguriert die E-Mail-Einstellungen des Babel Licensing Service. Mit dieser Konfiguration schalten Sie die E-Mail-Funktion ein und geben die Angaben an, die der Dienst für den Versand von E-Mails benötigt.

EnableSend: Legt fest, ob der E-Mail-Versand ein- oder ausgeschaltet ist. Bei true versucht der Babel Licensing Service, E-Mails gemäß den konfigurierten Einstellungen zu senden. Bei false ist der E-Mail-Versand ausgeschaltet.

Host: Der Hostname oder die IP-Adresse des E-Mail-Servers beziehungsweise SMTP-Servers (Simple Mail Transfer Protocol), über den die E-Mails gesendet werden. Geben Sie die passende Serveradresse ein.

Port: Die Portnummer, auf der der E-Mail-Server eingehende Verbindungen annimmt. In der Regel ist das der Port des SMTP-Servers. Der Standardport für SMTP ist 587, Sie können ihn aber entsprechend der Konfiguration Ihres E-Mail-Servers ändern.

UseSsl: Legt fest, ob die Verbindung zum E-Mail-Server mit SSL/TLS verschlüsselt wird. Bei true baut der Babel Licensing Service eine sichere Verbindung über SSL/TLS auf. Bei false wird eine ungesicherte Verbindung verwendet.

LocalDomain: Der lokale Domänenname für die E-Mail-Adressierung. Diese Einstellung ist optional und kann leer bleiben, wenn sie nicht benötigt wird.

Username: Der Benutzername oder Kontoname für die Authentifizierung beim E-Mail-Server. Geben Sie den passenden Benutzernamen ein.

Password: Das Passwort des E-Mail-Kontos. Geben Sie das Passwort ein, das zum angegebenen Benutzernamen gehört.

FromUser: Der Anzeigename oder Benutzername, der als Absender der E-Mails erscheint. Das kann ein frei gewählter Name oder ein tatsächlicher Benutzername sein.

FromAddress: Die E-Mail-Adresse, von der die E-Mails gesendet werden. Geben Sie eine gültige E-Mail-Adresse für den Absender ein.

To: Ein Array mit den E-Mail-Adressen und Namen der Empfänger. Jedes Empfängerobjekt sollte ein Feld „Name“ für den Namen des Empfängers und ein Feld „Email“ für seine E-Mail-Adresse enthalten. Tragen Sie die gewünschten Empfänger in das Array ein.

Licensing

Der Abschnitt „Licensing“ der Datei appsettings.json konfiguriert verschiedene Aspekte der Lizenzierungsfunktionen des Babel Licensing Service. Hier legen Sie Einstellungen zur Lizenzverwaltung und zum Verhalten der Lizenzierung fest.

Im Abschnitt „Licensing“ können Sie Parameter wie das Lebenszeichen-Intervall, das Format der Aktivierungstoken und das Format der Floating-Token angeben. Sehen wir uns diese Einstellungen genauer an:

"Licensing": {
  "HeartbeatInterval": "00:05:00",
  "LicenseIdFormat": "lic{HEX:8}",
  "CustomerCodeFormat": "C-{TOKEN:8}",
  "OrderNumberFormat": "O-{TOKEN:8}",
  "UserKeyFormat": "{TOKEN:5}-{TOKEN:5}-{TOKEN:5}-{TOKEN:5}",
  "ActivationTokenFormat": "actk_{token:12}",
  "FloatingTokenFormat": "fltk_{token:12}",
  "ReclaimInactiveActivationDays": 0
}

Heartbeat Interval: Dieser Parameter bestimmt den Abstand zwischen den Lebenszeichen, die der Lizenzdienst sendet. Das Lebenszeichen hilft, den Zustand und den Status des Lizenzierungssystems zu überwachen. Ein Floating-Token, das von seinem Client nicht freigegeben wird, läuft nach diesem Intervall ab.

ReclaimInactiveActivationDays: Neu in 12.0. Anzahl der Tage ohne Kontakt, nach denen eine Aktivierung freigegeben werden kann, wenn eine Lizenz alle ihre Plätze belegt hat und ein neuer Rechner die Aktivierung anfordert. Der Standardwert 0 schaltet die Funktion aus. Sie können den Wert auch über die Umgebungsvariable BABEL_SERVICE_LICENSING__RECLAIMINACTIVEACTIVATIONDAYS setzen. Lesen Sie Lizenztoken, bevor Sie die Funktion einschalten.

Formate für IDs und Schlüssel

Die in der Konfiguration angegebenen Formate verwenden eine Kombination von Platzhaltern, die durch zufällig erzeugte Werte ersetzt werden. TOKEN, HEX und DEC sind Platzhaltertypen, und die Zahl nach dem Doppelpunkt (:) gibt die Länge des erzeugten Werts an. Großbuchstaben (TOKEN, HEX) erzeugen Werte in Großbuchstaben, Kleinbuchstaben (token, hex) Werte in Kleinbuchstaben. DEC steht für Dezimalzahlen.

LicenseIdFormat: "lic{HEX:8}". Dieses Format erzeugt Lizenz-IDs, die mit „lic“ beginnen, gefolgt von 8 zufälligen hexadezimalen Zeichen in Großbuchstaben.

CustomerCodeFormat: "C-{TOKEN:8}". Kundencodes beginnen mit „C-“, gefolgt von 8 zufälligen alphanumerischen Zeichen in Großbuchstaben.

OrderNumberFormat: "O-{TOKEN:8}". Bestellnummern beginnen mit „O-“, gefolgt von 8 zufälligen alphanumerischen Zeichen in Großbuchstaben.

UserKeyFormat: "{TOKEN:5}-{TOKEN:5}-{TOKEN:5}-{TOKEN:5}". Benutzerschlüssel werden in einem Format mit vier Gruppen von je 5 zufälligen alphanumerischen Zeichen in Großbuchstaben erzeugt, die durch Bindestriche getrennt sind.

Activation Token Format: Diese Einstellung legt das Format der Aktivierungstoken fest, die im Lizenzierungsprozess verwendet werden. Aktivierungstoken werden erzeugt und den Benutzern bereitgestellt, damit sie ihre Lizenzen aktivieren und bestimmte Funktionen freischalten können. Der Standardwert „actk_{token:12}“ legt als Format des Aktivierungstokens das feste Präfix „actk_“ fest, gefolgt von 12 zufälligen Zeichen.

Floating Token Format: Ähnlich wie Aktivierungstoken werden Floating-Token für Floating-Lizenzen verwendet, mit denen Benutzer Lizenzen innerhalb eines festgelegten Pools auf mehreren Geräten oder unter mehreren Benutzern teilen können. Das Format der Floating-Token legt den Aufbau dieser Token fest. Der Standardwert „fltk_{token:12}“ legt als Format des Floating-Tokens das feste Präfix „fltk_“ fest, gefolgt von 12 zufälligen Zeichen.

Mit der Konfiguration des Abschnitts „Licensing“ passen Sie diese Parameter an Ihre Lizenzierungsanforderungen an. Diese Flexibilität erlaubt es, die Lizenzierungsfunktionen auf die Bedürfnisse Ihrer Anwendung oder Software abzustimmen.

Reporting

Der Abschnitt „Reporting“ der Datei appsettings.json konfiguriert die Einstellungen des Reportings im Babel Licensing Service. Hier legen Sie Parameter der Reporting-Funktionen fest, darunter Verschlüsselungsschlüssel für die sichere Übertragung und Speicherung von Berichten.

Im Abschnitt „Reporting“ können Sie Einstellungen wie den Verschlüsselungsschlüssel angeben. Sehen wir uns diese Einstellung genauer an:

"Reporting": {
  "EncryptionKey": ""
}

Encryption Key: Dieser Parameter legt den Verschlüsselungsschlüssel fest, mit dem die vom Babel Licensing Service erzeugten Berichte verschlüsselt und entschlüsselt werden. Durch die Verschlüsselung bleiben die vertraulichen Informationen in den Berichten sicher und vor unbefugtem Zugriff geschützt.

Mit der Konfiguration des Abschnitts „Reporting“ legen Sie den Verschlüsselungsschlüssel fest und stellen sicher, dass die vom Lizenzdienst erzeugten Berichte mit einem starken kryptografischen Algorithmus verschlüsselt werden. Diese Verschlüsselung fügt den Berichten eine weitere Sicherheitsebene hinzu und schützt vertrauliche Daten vor möglichen Bedrohungen oder Datenlecks.

Database

Babel Licensing Service 12.0 unterstützt SQL Server, MySQL/MariaDB, SQLite und PostgreSQL unter Windows, Linux und macOS. Babel Desktop verbindet sich mit dem Dienst, nicht direkt mit dessen Datenbank.

Anbieter auswählen

Setzen Sie Database.Provider auf den exakten Namen in der Tabelle und konfigurieren Sie den passenden Eintrag unter ConnectionStrings. MariaDB verwendet MySQL. Postgres, SQL Server und MariaDB sind keine gültigen Anbieternamen. Nur der ausgewählte Eintrag wird verwendet.

Schema und Migrationen

{
  "Database": {
    "Provider": "PostgreSQL",
    "EnableMigration": true,
    "EnableDetailedErrors": false,
    "MaxRetryCount": 5,
    "MaxRetryDelay": "00:00:30"
  }
}

EnableMigration=true führt beim Dienststart die Schemamigrationen des Anbieters aus; dafür benötigt das Konto die entsprechenden Rechte. Bei false muss das Schema bereits aktuell sein. Ein Anbieterwechsel überträgt keine Daten. Sichern Sie die Datenbank und testen Sie das Upgrade auf einer Kopie. Beenden Sie vor dem Backup einer SQLite-11.8-Datei die alte Anwendung und testen Sie den Dienst 12.0 mit der Kopie.

EnableDetailedErrors steuert zusätzliche Fehlerdetails. MaxRetryCount und MaxRetryDelay gelten für vorübergehende Fehler bei SQL Server, MySQL und PostgreSQL, nicht für SQLite. Starten Sie den Dienst nach Konfigurationsänderungen neu.

Verbindungszeichenfolgen je Anbieter

Die vollständigen JSON-Beispiele werden in appsettings.json zusammengeführt. Ersetzen Sie Host, Pfad, Benutzer und REPLACE_WITH_PASSWORD. Die Netzwerkbeispiele benötigen TLS auf dem Datenbankserver und ein vertrauenswürdiges Zertifikat.

SQL Server

{
  "Database": {
    "Provider": "SQLServer"
  },
  "ConnectionStrings": {
    "SQLServer": "Server=db.example.com,1433;Database=licenses;User ID=babel_licensing;Password=REPLACE_WITH_PASSWORD;Encrypt=True;TrustServerCertificate=False;Connect Timeout=30"
  }
}

Server enthält Host und optional den TCP-Port nach einem Komma. Database, User ID und Password wählen Datenbank und Konto. Encrypt=True;TrustServerCertificate=False verschlüsselt und prüft das Zertifikat. Unter Windows können die SQL-Anmeldedaten durch Integrated Security=True ersetzt werden. LocalDB ist nur eine Windows-Entwicklungsoption.

Treiberreferenz: SQL Server .

MySQL / MariaDB

{
  "Database": {
    "Provider": "MySQL"
  },
  "ConnectionStrings": {
    "MySQL": "Server=db.example.com;Port=3306;Database=licenses;User ID=babel_licensing;Password=REPLACE_WITH_PASSWORD;SslMode=VerifyFull;Connection Timeout=30"
  }
}

MySQL und MariaDB verwenden MySQL. Server, Port, Database, User ID und Password wählen die Verbindung. SslMode=VerifyFull prüft Zertifikat und Hostnamen. Für eine private CA ergänzen Sie SslCa=/pfad/ca.pem. Verwenden Sie ein eigenes Dienstkonto statt root.

MySQL und MariaDB verwenden auf jedem Framework den Anbieter MySQL. Die Dienste für .NET 6 bis 9 verwenden Pomelo.EntityFrameworkCore.MySql. Der Dienst für .NET 10 verwendet Microting.EntityFrameworkCore.MySql 10.0.11, einen Pomelo-Fork unter MIT-Lizenz, der Entity Framework Core 10 unterstützt. Ab Version 12.0 läuft der Dienst für .NET 10 mit MySQL und MariaDB. Verbindungszeichenfolgen und Datenbankschema sind identisch. Getestet mit MySQL 8.4 und MariaDB 11.4.

Treiberreferenz: MySQL / MariaDB .

PostgreSQL

{
  "Database": {
    "Provider": "PostgreSQL"
  },
  "ConnectionStrings": {
    "PostgreSQL": "Host=db.example.com;Port=5432;Database=licenses;Username=babel_licensing;Password=REPLACE_WITH_PASSWORD;SSL Mode=VerifyFull;Timeout=30"
  }
}

PostgreSQL verwendet Npgsql mit Host, Port, Database, Username und Password. Dies ist eine .NET-Verbindungszeichenfolge, keine postgresql://-URL. SSL Mode=VerifyFull prüft Zertifikat und Hostnamen; bei privater CA ergänzen Sie Root Certificate=/pfad/ca.pem. Datenbank und Rolle müssen existieren; die Rolle benötigt Zugriff auf Schema und Tabellen.

Treiberreferenz: PostgreSQL .

SQLite

{
  "Database": {
    "Provider": "SQLite"
  },
  "ConnectionStrings": {
    "SQLite": "Data Source=/var/lib/babel/licenses.db;Mode=ReadWriteCreate;Foreign Keys=True;Default Timeout=30"
  }
}

SQLite läuft im Licensing Service ohne separaten Datenbankserver oder Zugangsdaten. Data Source ist ein absoluter Dateipfad auf dem Dienstrechner. Mode=ReadWriteCreate erstellt fehlende Dateien; Mode=ReadWrite setzt eine vorhandene Datei voraus. Das Dienstkonto benötigt Schreibrechte auf Datei und Verzeichnis einschließlich Journal/WAL. Verwenden Sie in Docker ein dauerhaftes, beschreibbares Volume.

Windows-Pfad mit JSON-Escaping:

{
  "ConnectionStrings": {
    "SQLite": "Data Source=C:\\Babel\\Data\\licenses.db;Mode=ReadWriteCreate;Foreign Keys=True;Default Timeout=30"
  }
}

Foreign Keys=True aktiviert Fremdschlüssel. Default Timeout=30 gibt das Befehlstimeout in Sekunden an. Relative Pfade wie licenses.db hängen vom Arbeitsverzeichnis des Dienstes ab.

Konfigurieren und starten Sie den Licensing Service selbst, auch für lokales SQLite. Babel Desktop installiert, startet oder beendet ihn nicht; das Desktop-Profil verbindet sich mit seinem HTTP/HTTPS-Endpunkt.

Treiberreferenz: SQLite .

Umgebungsvariablen

Variablen mit BABEL_SERVICE_ überschreiben JSON-Werte. Zwei Unterstriche trennen die Ebenen. Setzen Sie nur den Verbindungseintrag des ausgewählten Anbieters. Verwenden Sie für echte Geheimnisse den Secret Store Ihrer Bereitstellung.

export BABEL_SERVICE_Database__Provider=PostgreSQL
export BABEL_SERVICE_ConnectionStrings__PostgreSQL='Host=db.example.com;Port=5432;Database=licenses;Username=babel_licensing;Password=REPLACE_WITH_PASSWORD;SSL Mode=VerifyFull'

Werte mit Semikolon müssen gemäß Treibersyntax in Anführungszeichen stehen. Maskieren Sie innere Anführungszeichen und Windows-Backslashes zusätzlich für JSON.