Skip to content

Skalierung

Für den skalierten Betrieb sind einige Konfigurationsarbeiten erforderlich.

Clock drift

Es wird mit Zeitstempeln gearbeitet. Daher müssen alle CMI STS Instanzen über eine synchronisierte Zeit mit einer maximalen Drift von wenigen Sekunden verfügen. Alle Instanzen sollten mit dem selben NTP-Server synchronisiert sein.

Forwarded Proxy Headers

In einem skalierten Betrieb wird wahrscheinlich ein Proxy eingesetzt. Damit der CMI STS mit den Proxy korrekt zusammenarbeitet, muss die Verarbeitung der Forwarded-Header aktiviert werden.

Signing Keys

Der CMI STS 3 stellt signierte Tokens mit einem Private-/Public-Schlüsselpaar aus. Werden mehrere Instanzen ausgeführt, muss jede Instanz das gleiche Private-/Public-Schlüsselpaar verwenden. Dazu müssen die Schlüssel auf einem gemeinsam zugreifbaren Speicher abgelegt werden. Siehe auch Token-Signierung.

{
    "KeyManagement": {
        "KeyPath": "<shared directory path>"
    }
}

Persisted Grant Store

Viele Grant-Typen erfordern eine Persistenz und müssen für alle CMI STS Instanzen verfügbar sein. Dazu gehören Autorisierungscodes, Aktualisierungstoken, Referenztoken und gespeicherte Benutzerzustimmungen (Consents).

Es werden folgende Implementierungen für den Persisted Grant Store unterstützt:

  1. InMemory: Standardmässig wird der Store im Arbeitsspeicher gehalten. Da jede CMI STS Instanz so einen eigenen Store verwendet, muss für den skalierten Betrieb eine andere Implementierungen verwendet werden.
  2. Datei-basiert: Die Grant-Daten werden als Datei gespeichert. Ein Share-Verzeichnis, beispielsweise via SMB oder NFS, kann verwendet werden um die Dateien für alle CMI STS Instanzen bereitzustellen. Diese Methode kann bei geringer Last auf die CMI STS Instanzen verwendet werden. Die Bereitstellung ist relativ einfach, da lediglich eine gemeinsame Datenfreigabe eingerichtet werden muss. Mehr als zwei CMI STS Instanzen sollten mit dieser Methode nicht betrieben werden.
  3. Redis: Die Grant-Daten werden in der In-Memory-Datenbank Redis gespeichert. Diese Methode eignet sich bei hoher Last auf die CMI STS Instanzen oder bei einer grösseren Anzahl Instanzen. Zum Einrichten eines In-Memory-Datenbank-Servers kann die Dokumentation des Herstellers konsultiert werden.

Hinweis: Es kann nur eine Implementierung zu selben Zeit verwendet werden. Werden beide Implementierungen konfiguriert, wird Redis verwendet.

Datei-basierter Persisted Grant Store

Um den Datei-basierten Persisted Grant Store zu aktivieren, wird die Sektion FilePersistedGrantStore konfiguriert.

{
  "FilePersistedGrantStore": {
    "Path": "<path to folder>",
    "EnableCleanup": true,
    "CleanupIntervalSeconds": 300
  }
}
  • Path: Wenn ein Pfad konfiguriert wird, wird der CMI STS die "Persisted Grants" in den angegebenen Pfad schreiben und lesen. Ansonsten erfolgt die Datenhaltung im Memory.
  • EnableCleanup (optional, Standardwert: true): Es gibt Situationen, bei denen Grants nicht automatisch wieder entfernt werden. Zum Beispiel wenn eine Anmeldung durch den Client auf halben Weg abgebrochen wird. Wenn diese Option aktiviert ist, werden abgelaufene Grants regelmässig entfernt. Bei vielen CMI STS Instanzen kann es sinnvoll sein, diese Option nicht bei allen Instanzen zu aktivieren, um das Dateisystem nicht mit permanenten Zugriffen zu belasten.
  • CleanupIntervalSeconds (optional, Standardwert: 300): Intervall in Sekunden, in dem nach abgelaufenen Grants gesucht wird. Ein Grant hat üblicherweise eine Gültigkeit von einigen Minuten.

Bei den auf dem Dateisystem gespeicherten "Persisted Grants" handelt es sich um JSON-Dateien. Es ist möglich, abgelaufene Grants alternativ auch durch ein Script regelmässig zu entfernen. Dazu muss die Eigenschaft Expiration überprüft werden. Es handelt sich um ein Datum nach ISO 8601.

Der Grant kann entfernt werden, wenn Expiration nicht null ist und das Datum in der Vergangenheit liegt.

Redis Persisted Grant Store

Um den Redis Persisted Grant Store zu aktivieren, wird das Attribut RedisPersistedGrantStore konfiguriert.

{
  "RedisPersistedGrantStore": "<redis connection string>"
}

ASP.NET Core distributed caching

Beim CMI STS handelt es sich um eine ASP.NET Core Anwendung. Sie bezieht von diesem Framework den Service ASP.NET Core distributed caching. Die Cache-Daten müssen für alle skalierten CMI STS Instanzen verfügbar sein.

Es werden folgende Implementierungen für den Distributed Cache unterstützt:

  1. InMemory: Standardmässig wird der Cache im Arbeitsspeicher gehalten. Da jede CMI STS Instanz so einen eigenen Cache verwendet, muss für den skalierten Betrieb eine andere Implementierungen verwendet werden.
  2. Datei-basiert: Die Cache-Daten werden als Datei gespeichert. Ein Share-Verzeichnis, beispielsweise via SMB oder NFS, kann verwendet werden um die Dateien für alle CMI STS Instanzen bereitzustellen. Diese Methode kann bei geringer Last auf die CMI STS Instanzen verwendet werden. Die Bereitstellung ist relativ einfach, da lediglich eine gemeinsame Datenfreigabe eingerichtet werden muss. Mehr als zwei CMI STS Instanzen sollten mit dieser Methode nicht betrieben werden.
  3. Redis: Die Cache-Daten werden in der In-Memory-Datenbank Redis gespeichert. Diese Methode eignet sich bei hoher Last auf die CMI STS Instanzen oder bei einer grösseren Anzahl Instanzen. Zum Einrichten eines In-Memory-Datenbank-Servers kann die Dokumentation des Herstellers konsultiert werden.

Hinweis: Es kann nur eine Implementierung zu selben Zeit verwendet werden. Werden beide Implementierungen konfiguriert, wird Redis verwendet.

Passwort-Link Nonce: Nonces für Passwort-Reset-Links werden im DistributedCache gespeichert und von ihm verwaltet. Siehe im Kapitel Passwort-Link Nonce.

Datei-basierter Cache

Um den Datei-basierten Cache zu aktivieren, wird die Sektion FileDistributedCache konfiguriert.

{
  "FileDistributedCache": {
    "Path": "<path to folder>",
    "EnableCleanup": true,
    "CleanupIntervalSeconds": 300
  }
}
  • Path (erforderlich): Wenn ein Pfad konfiguriert wird, wird der CMI STS die Cache-Daten in den angegebenen Pfad schreiben und lesen. Ansonsten erfolgt die Datenhaltung im Memory.
  • EnableCleanup (optional, Standardwert: true): Wenn diese Option aktiviert ist, werden abgelaufene Cache-Daten regelmässig entfernt. Bei vielen CMI STS Instanzen kann es sinnvoll sein, diese Option nicht bei allen Instanzen zu aktivieren, um das Dateisystem nicht mit permanenten Zugriffen zu belasten.
  • CleanupIntervalSeconds (optional, Standardwert: 300): Intervall in Sekunden, in dem nach abgelaufenen Cache-Daten gesucht wird. Cache-Daten haben üblicherweise eine Gültigkeit von wenigen Stunden.

Hinweis: Der CMI STS verwendet keine abgelaufenen Cache-Daten, auch wenn sich die abgelaufenen Cache-Daten noch auf dem Dateisystem befinden. Eine verzögerte Dateibereinigung ist kein Problem. In den meisten Fällen werden Cache-Daten vom CMI STS vorzeitig entfernt, da die meisten Cache-Daten mit dem Abschluss eines Authorization-Flows invalidiert werden.

Tipp: Wird NFS verwendet um die Dateien für alle CMI STS 3 Instanzen verfügbar zu machen, werden folgende NFS-Client-Mount-Optionen empfohlen: * lookupcache=none * sync * noac

Bei den auf dem Dateisystem gespeicherten Cache-Daten handelt es sich um je eine JSON-Datei (.meta.json, Cache-Metadaten) und die dazugehörige Cache-Datei (.payload). Es ist möglich, abgelaufene Cache-Items alternativ auch durch ein Script regelmässig zu entfernen. Das Script muss folgende Regeln einhalten:

  1. .payload-Dateien ohne zugehörige .meta.json-Datei können gelöscht werden.
  2. Eine .payload-Datei und ihre zugehörige .meta.json-Datei kann entfernt werden wenn:
  3. Die Eigenschaft CacheOptions.AbsoluteExpiration nicht null ist und der Wert (Datum, ISO 8601) in der Vergangenheit liegt.
  4. Die Eigenschaft CacheOptions.SlidingExpiration nicht null ist und die Summe von CacheOptions.SlidingExpiration (Dauer, ISO 8601) und LastAccess (Datum, ISO 8601) in der Vergangenheit liegt.

Redis Cache

Um den Redis Cache zu aktivieren, wird das Attribut RedisDistributedCache konfiguriert.

{
  "RedisDistributedCache": "<redis connection string>"
}

ASP.NET Core Data Protection system

Beim CMI STS handelt es sich um eine ASP.NET Core Anwendung. Sie bezieht von diesem Framework den Service ASP.NET Core Data Protection system. Die kryptografischen Schlüssel (Key Ring) müssen für jede Instanz verfügbar sein.

Standardmässig verwaltet jede CMI STS Instanz ihren eigenen Key-Ring. Im skalierten Betrieb müssen alle Instanzen den selben Key-Ring verwenden.

Wichtig: Die Parameter von DataProtection haben nur einen Effekt, wenn ein ApplicationName konfiguriert wurde. 

{
    "DataProtection": {
        "ApplicationName": "CMI_STS",
        "KeyPersistenceDirectory": "<path to folder>",
        "KeyPersistenceCertificate": "<path to pfx certificate>",
        "KeyPersistenceKey": "<pfx password>",
        "DisableAutomaticKeyGeneration": false
    }
}
  • ApplicationName (optional): Alle skalierten CMI STS Instanzen müssen den selben Anwendungsnamen verwenden. Der Name kann beliebig gewählt werden.
  • KeyPersistenceDirectory (optional): Anstatt den Key-Ring in %LOCALAPPDATA% zu speichern, wird der Key-Ring in den angegeben Pfad geschrieben oder gelesen. Alle CMI STS Instanzen müssen auf diesen Pfad Zugriff haben, um den selben Key-Ring zu verwenden. Wichtig: Dies deaktiviert die automatische Verschlüsselung des Key-Rings (encrypt at rest).
  • KeyPersistenceCertificate (optional, ergänzt KeyPersistenceDirectory): Pfad zu einem PFX-Zertifikat mit Private-Key, das zum verschlüsseln des Key-Rings verwendet werden soll. Dies aktiviert "encrypt at reset".
  • KeyPersistenceKey (erforderlich für KeyPersistenceCertificate): Passwort um das PFX-Zertifikat zu öffnen. Die Konfiguration enthält alle Informationen, damit der Key-Ring entschlüsselt werden kann und muss daher geschützt werden.
  • DisableAutomaticKeyGeneration (optional, Standardwert: false): Wenn true, deaktiviert dies die automatische Erzeugung und Erneuerung von Key-Ringen. Die Erzeugung kann bei Bedarf einer "primären" CMI STS Instanz überlassen werden. Wenn diese Option bei allen CMI STS Instanzen deaktiviert wird, muss der Key-Ring über einen externen Prozess erzeugt werden und regelmässig ersetzt werden.

Wichtig: Die Verschlüsselung des Key-Rings mittels PFX-Zertifikat macht nur dann Sinn, wenn die Konfiguration besser geschützt werden kann, als der Key-Ring-Pfad (KeyPersistenceDirectory).

Wichtig: Der Speicherort für den Key-Ring des Data Protection Systems muss mit den entsprechenden Berechtigungen geschützt werden. Sie können eine verschlüsselte Speicherung des Key-Rings konfigurieren (encrypt at rest), das hindert einen Angreifer jedoch nicht daran, die Schlüssel neu zu generieren und auszutauschen, wenn der Zugriff auf den Speicherort möglich ist. Der Zugriff auf den Speicherort sollte ausschliesslich auf die Anwendung beschränkt sein, beispielweise durch Dateisystemberechtigungen.