Was läuft, bestimmt die Konfiguration

Worum es geht

CIAS ist keine Anwendung, die man startet, sondern eine Sammlung von Jars. Ein Jar ist eine Bibliothek, die im Klassenpfad einer Anwendung liegt. Ob ein CIAS-Modul in dieser Anwendung tatsächlich arbeitet, entscheidet allein die Konfiguration. Dass das Jar da ist, reicht nicht.

Warum kein Modul sich selbst einschaltet

Spring findet Klassen normalerweise über einen Komponentenscan: Es durchsucht Pakete nach Klassen mit Markierungen wie @Service oder @Component und baut sie zusammen. CDMS scannt dabei alles unter com.codamai — und CIAS liegt unter com.codamai.

Trüge eine CIAS-Klasse so eine Markierung, würde jede CDMS-Anwendung sie einsammeln, sobald das Jar irgendwie im Klassenpfad landet, etwa als Abhängigkeit einer Abhängigkeit. Zusammengesteckt würde sie dann mit Objekten, die es dort gar nicht gibt.

Deshalb:

Die Schalter

Das Bild zeigt, wo die Schalter sitzen. Links das, was immer da ist, sobald die Filterkette läuft; rechts die Module, die einzeln zugeschaltet werden.

flowchart LR
    subgraph P["Ein Prozess"]
        direction TB
        A["Filterkette, Mandanten-Tor<br/><i>kein Schalter: da oder nicht da</i>"]
        L{"codamai.cias.tenancy.lookup"}
        A --> L
        L -->|local| T["Mandantenverwaltung<br/>codamai.cias.tenancy.enabled"]
        L -->|remote| C["Mandanten-Client<br/>+ client.base-url, client.credentials"]
        A -.-> U["Benutzerverwaltung<br/>codamai.cias.user.enabled"]
        A -.-> Z["Rollenverwaltung<br/>codamai.cias.authorization.enabled"]
        A -.-> R["Registrierung<br/>codamai.cias.registration.enabled"]
        A -.-> N["Mailversand<br/>codamai.cias.notification.enabled"]
        A -.-> AU["Audit<br/>codamai.cias.audit.enabled"]
    end
    IP{"codamai.cias.iam-provider"}
    Z --> IP
    U --> IP
    IP -->|keycloak| K[(Keycloak)]

Die vollständige Liste:

Die Filterkette hat keinen eigenen Schalter. Sie prüft jedes Token, und sie arbeitet, sobald ihr Jar da ist. Was sie braucht, ist kein Schalter, sondern eine Antwort: codamai.cias.tenancy.lookup sagt ihr, wen sie nach dem Mandanten fragt.

Die drei Ausprägungen

Wann welcher Fall gilt, ist nicht Geschmackssache. Es hängt davon ab, was ein falscher Standardwert anrichten würde:

Die ganze Regel dahinter steht unter Im Zweifel ablehnen, samt der Liste aller Pflicht-Angaben.

Was die Anwendung selbst beisteuern muss

Manche Angaben sind keine Zeile in einer Datei, sondern Beans. Eine Bean ist ein Objekt, das Spring beim Start zusammensteckt.

Fehlt eine davon, wo sie gebraucht wird, scheitert der Start mit dem Namen des Typs in der Meldung.

Was im Build entschieden wird

Ein Teil der Entscheidung fällt früher, nämlich wenn der Projektrahmen erzeugt wird. Ein Feld dafür gibt es nicht. Der Generator leitet die Einbindung aus zwei Angaben im Hub ab: ob das System über CIAS anmeldet (authentication) und in welcher Runtime das CIAS-Modul des Projekts läuft.

Ein abgelehnter Build antwortet mit 400, und die Meldung nennt, was zu modellieren ist: dem Projekt ein CIAS-Modul geben, es in eine Runtime setzen oder authentication auf NONE stellen.

Zwei Dinge daran sind leicht zu übersehen:

• Die Einbindung kann für zwei CDMS-Module desselben Projekts verschieden sein. Läuft das CIAS-Modul in der Runtime des einen, ist es dort eingebettet, und das andere in seiner eigenen Runtime ist sein Client. Einen eigenen CIAS-Dienst braucht das zweite dafür nicht.
• Bei EMBEDDED entscheidet das CIAS-Modul, was eingeschaltet ist. Die application.yaml des Rahmens lässt Benutzer, Rollen und Keycloak-Zugriff aus. Die erzeugte cias-configuration.yaml setzt sie auf das, was am CIAS-Modul im Hub eingestellt ist. Eine Umgebungsvariable wie CIAS_USER überschreibt beides. Auch hier gilt: Was läuft, bestimmt die Konfiguration, nicht der Klassenpfad.

Fallen

Weiter

• Eingebettet und getrennt im Vergleich
• CIAS eingebettet (eine Einheit)
• CIAS als eigener Service
• SINGLE und MULTI über beide Module
• Im Zweifel ablehnen
• Wer entscheidet was?