Inhaltsverzeichnis
Jede Zeile nennt Pfad, Inhalt und die Ausprägungen, die dort vollständig behandelt werden. Stand: 213 Themen, davon 213 fertig, 0 im Entwurf, 0 geplant.
CDMS – Daten
Die Datenschicht von CodamAI. Aus einem Modell entsteht eine REST-API, die Daten liest, sucht, schreibt und löscht, dabei jede Anfrage auf Rechte und Mandant prüft und jede Änderung protokolliert.
1. Grundlagen: Modell, Schichten, Endpunkte
Was ein CDMS-Modell ist, auf welcher Ebene seine Daten liegen, durch welche Schichten eine Anfrage läuft und welche Endpunkte ein Modell bekommt.
| 1.1 Modell-Ebenen: System, Mandant, Benutzercdms/grundlagen/modell-ebenen | Jedes Modell gehört zu einer von drei Ebenen. Die Ebene entscheidet, in welcher Datenbank die Daten liegen und ob jemand nur seine eigenen Zeilen sieht. SYSTEM (immer System-DB)TENANT (Mandanten-DB)USER (Mandanten-DB + Besitzer _userId)Betriebsart MULTIBetriebsart SINGLEohne Angabe → TENANTUntertypen erben die EbeneBeziehungen über Ebenen hinwegtechnischer Client bei USER-Modellen |
| 1.2 Ein Modell, vier Gestaltencdms/grundlagen/modell-gestalten | Ein Modell existiert zur Laufzeit als Entity (Datenbank), DTO (Antwort), Payload (Eingabe) und Metadaten (Beschreibung). Hier steht, wann welche Gestalt im Spiel ist und wie gemappt wird. EntityDTOCreatePayloadUpdatePayloadPATCH mit freier MapReferenz als IdWrapper {id, @type}Referenz als verschachtelte PayloadMeta (MetaClassInfo, MetaFieldInfo, MetaFieldRules)Anlegen, Ersetzen, Ändern, Lesen |
| 1.3 Systemfelder, die der Server setztcdms/grundlagen/systemfelder | Felder wie id, _createdOn, _userId, _MODELTYPE und _version setzt CDMS selbst. Hier steht, wann welches Feld gesetzt wird und was der Client davon mitschicken darf.id_createdOn_updatedOn_userId (nur USER-Modelle)_MODELTYPE / @type_version (nur Datei-Modelle)interne Hilfsfeldervom Client mitgeschickt → ignoriert |
| 1.4 Der Weg einer Anfrage durch die Schichtencdms/grundlagen/request-weg | Filterkette, REST-Layer, System-Layer, Persistenz, Commit: was jede Station prüft, was sie entscheidet und mit welchem Fehler sie abbricht. Getrennt für Lese- und Schreibvorgänge. LesevorgangAnlegenÄndern und Löschen (mit Sichtbarkeitsprüfung)SuchenErfolg: Commit vor der AntwortFehler: RollbackAbbruch an jeder Station |
| 1.5 Welche Endpunkte ein Modell hatcdms/grundlagen/endpunkte | Der feste Satz von Operationen pro Modell (create, read, update, delete, query, history, rollback, Datei) und wie die Endpunkt-Liste im Modell einzelne Operationen ein- und ausschaltet. StandardsatzEndpunkt-Liste leer = alles außer HistorieUPDATE schaltet PUT und PATCHREAD ohne QUERYHISTORY / HISTORY_ROLLBACKUPLOAD / DOWNLOADSingleton-Modellabstraktes Modell (Hub-API)Datei-Modellnicht vorhanden → 404 |
| 1.6 Singletons: genau ein Objektcdms/grundlagen/singleton | Manche Modelle gibt es nur einmal pro Scope, etwa Einstellungen eines Benutzers. Hier steht, wie die Pfade ohne ID funktionieren und was bei doppeltem Anlegen oder fehlendem Objekt passiert. Singleton pro Systempro Mandantpro Benutzeranlegen, lesen, ersetzen, ändern, löschenzweites Create → 400Lesen/Ändern ohne Objekt → 404Löschen ohne Objekt → keine WirkungDatei, Historie und Rollback |
1.7 Abstrakte Modelle und @typecdms/grundlagen/abstrakte-modelle | Ein Oberbegriff mit mehreren konkreten Typen, etwa „Kunde“ mit Privat- und Firmenkunde. Hier steht, wie die Hub-API Anfragen an den richtigen Untertyp weiterleitet und wann der Client @type angeben muss.anlegen mit @typeersetzen und ändern mit @typelesen und löschen: Typ über die idSuche in zwei Phasenparallele LeseschritteEndpunkte der Untertypen direktRechte und Filter der Untertypenunbekannter Typ |
1.8 Das Antwortformat: data und metacdms/grundlagen/antwortformat | Jede Antwort hat dieselbe Hülle. Hier steht, was in data und meta steckt, bei Einzelobjekt, Liste, Historie und Fehler.Einzelobjekt (SingleResponse)Liste (QueryResponse)Historie (AuditQueryResponse)FehlerValidierungsfehler mit violationsangelegt, aber nicht zurückgelesenDELETE ohne KörperDatei-Download |
2. Vom Modell zur Anwendung
Wie aus einem Modell im Hub lauffähiger Code wird: modellieren, Metadaten holen, generieren, Projektrahmen, und wie Schemaänderungen kontrolliert über den MCP-Server laufen.
| 2.1 Modellieren im Hubcdms/modellieren/hub-modellieren | Was man im Hub festlegt: System, Ordner, Modell, Feld, Beziehung, Regeln, Endpunkte, Rechte. Und welche Modellierungsregeln gelten. System (Modul)Ordner und EnumerationDatenmodell, abstraktes Modell, Datei-ModellPrimitivfeld, Enum-Feld, BeziehungsfeldRegeln am FeldEndpunkteRechteZugriffsfilter und Hooks |
| 2.2 Codegenerierung im Buildcdms/modellieren/generierung | Der Build holt die Metadaten aus dem Hub, legt sie als YAML-Cache ab und erzeugt daraus 15 Klassen pro Modell. Hier steht der Ablauf und was wann entsteht. online (Metadaten per REST)offline (CODEGEN_OFFLINE, vorhandener Cache)Abruf ganz überspringen (cdms.generator.fetch.skip)Export aus dem Hub als ZIPpro Modelleinmal pro Buildnur beim ersten Mal |
| 2.3 Der Projektrahmen (Scaffold)cdms/modellieren/projektrahmen | Was ein neues Projekt beim ersten Mal bekommt (POM, Start-Klasse, Konfiguration) und welche Zweige es gibt, z. B. CIAS eingebettet oder entfernt. Authentifizierung OIDC oder NONECIAS EMBEDDED / REMOTE / NONEDatenbank MYSQL / MARIADBSpeicher FILESYSTEM oder NONEMonitoring ACTUATOR oder NONEAuditing (abgeleitet)erster Download, späterer Build |
| 2.4 Generierter Code und eigener Codecdms/modellieren/generiert-und-eigen | Warum generierter Code nie von Hand geändert wird und wo eigener Code hingehört: Hooks, eigene Filter, eigene Controller und Services, Konfiguration. generiert, nicht anfassenHookeigener FilterAttributfiltereigener Controller oder ServiceKonfiguration |
| 2.5 Schemaänderung über den MCP-Servercdms/modellieren/mcp-aenderung | Wie ein KI-Client über den MCP-Server des Hubs ein Modell ändert: lesen, Blueprint validieren, Change Set planen, freigeben, genau einmal anwenden. nur lesenBlueprint validierenChange Set planenfreigebendestruktive Änderung freigebenanwendenzweiter Apply gleichzeitigzurücknehmen (Rollback)Operation Context: ein Ziel-CDMSfremde operationIdBlueprint mit UmgebungBasis hat sich geändertClaude Code anbindenanderer MCP-Client |
3. Daten lesen
Ein Objekt lesen und genau bestimmen, welche Felder und Referenzen zurückkommen: Feldauswahl, Wildcards, verschachtelte Referenzen, abstrakte Typen, und was dabei in der Datenbank passiert.
| 3.1 Ein Objekt lesencdms/lesen/einzelobjekt | Wie POST /read/{id} und GET /read/{id} ablaufen, was bei fehlendem oder unsichtbarem Objekt zurückkommt und worin sich Singleton und abstraktes Modell unterscheiden.POST /read/{id} mit responseGET /read/{id} (= *)Singleton POST/GET /readabstraktes Modellnicht vorhanden → 404unsichtbar → 404ohne Leserolle → 403Referenz ohne Leserolle → 403response fehlt → 400 |
3.2 Feldauswahl mit responsecdms/lesen/feldauswahl | Die Liste response bestimmt, was zurückkommt, und ist Pflicht. Hier stehen die möglichen Einträge und was bei fehlender Liste oder unbekannten Feldern passiert.FeldnameWildcardObjekt {field, response}excluderesponse fehlt → 400leere Liste → nur Systemfelderunbekanntes Feld → still ignoriertObjekt auf einfachem Feld → ignoriertRechte gelten pro Modell, nicht pro Feld |
| 3.3 Wildcards + und *cdms/lesen/wildcards | Wie du mit + und * viele Felder auf einmal anforderst, was die Teil-Wildcards name+, +name, name* und *name treffen und warum * mehr Rechte braucht, als man denkt.+ allein* alleinPräfix: name+ / name*Suffix: +name / *nameKombination mehrerer EinträgeexcludeWildcard ohne TrefferMarker in der WortmitteGET /read = ** ohne Leserecht auf Referenz |
| 3.4 Referenzen und Listen ausbauencdms/lesen/referenzen-ausbauen | Wie eine Referenz mit { field, response } vollständig geladen wird, wie Listen eigene Filter, Sortierung und Seitengröße bekommen und wie tief das gehen darf.EinzelreferenzEinzelreferenz nicht gesetzt oder unsichtbar → nullListeListe mit parametermehrere EbenenRückreferenz wird automatisch ergänztkeine Trefferzahl für UnterlistenReferenz ohne Leserolle → 403 |
| 3.5 Lesen über abstrakte Typencdms/lesen/abstrakte-referenzen | Zeigt eine Referenz auf ein abstraktes Modell, liefert CDMS die Felder aller möglichen Untertypen. Hier steht, wie das aufgelöst wird und wie der Client die Typen unterscheidet. abstrakte Einzelreferenzabstrakte Liste@type in der Antwort+ heißt: Felder aller UntertypenFeld nur eines UntertypsRechte des Untertyps |
| 3.6 Was beim Lesen in der Datenbank passiertcdms/lesen/datenbankwirkung | Die Feldauswahl steuert die SQL-Abfrage: nur die verlangten Spalten, Referenzen per LEFT JOIN, kein Nachladen im Hintergrund. Hier steht, warum das schnell ist und wann es teuer wird. Tuple-ProjektionLEFT JOINzählen, IDs bestimmen, Felder holenausgebaute Einzelreferenz als eigenes LesenUnterlisten als eigene Abfragentiefe VerschachtelungUntertypen abstrakter Modelle |
4. Suchen, Filtern, Blättern
Listen abfragen mit POST /query: Filterbaum aus UND/ODER-Gruppen, alle Operatoren, Suchmuster mit LIKE, Pfade über Beziehungen, Sortierung, Seiten und die Filter, die der Server immer dazunimmt.
| 4.1 Aufbau einer Suchecdms/suchen/query-aufbau | Wie ein Such-Request aussieht: response, parameter mit query, order, page, limit, meta, und welche Standardwerte gelten.minimale Suchemit Filtermit Sortierungmit Seitenohne parameterohne Leserolle → 403 |
| 4.2 Alle Filteroperatorencdms/suchen/operatoren | EQ, NEQ, LIKE, IN, ISNULL, ISNOTNULL, BEFORE, AFTER, SAMEORBEFORE, SAMEORAFTER, MEMBEROF: was jeder bedeutet, für welche Feldtypen er gilt und wie der Wert geschrieben wird. EQNEQLIKEIN (kommagetrennter String)ISNULLISNOTNULLBEFOREAFTERSAMEORBEFORESAMEORAFTERMEMBEROFOperator passt nicht zum Feldtyp |
| 4.3 Suchmuster mit LIKE: % und _cdms/suchen/like-suchmuster | Wie die Platzhalter % und _ in einer LIKE-Suche wirken, warum CDMS kein % automatisch ergänzt, dass es kein Escaping gibt und wovon Groß- und Kleinschreibung abhängt.exakter Wert ohne %beginnt mit (abc%)endet auf (%abc)enthält (%abc%)genau ein Zeichen (_)% oder _ als echtes ZeichenGroß-/Kleinschreibung je DatenbankLIKE ist der StandardoperatorLIKE auf Nicht-Text-Feld |
| 4.4 UND/ODER-Gruppencdms/suchen/und-oder-gruppen | Wie type, filter und group einen Filterbaum bilden, warum der Standard ODER ist und wie aus dem Baum eine Bedingung wird.eine Gruppe ANDeine Gruppe OR (Standard)verschachtelte GruppenODER-Gruppe mit filter und groupvergessenes typeleere Gruppe |
| 4.5 Filtern und Sortieren über Beziehungencdms/suchen/pfade | Punktnotation wie customer.address.city: wie CDMS dafür verknüpft und warum Objekte ohne Beziehung nicht herausfallen.ein Schrittmehrere SchritteObjekt ohne Beziehung (LEFT JOIN)über eine ListeID der Referenzunbekannter PfadSortieren über Pfad |
| 4.6 Sammlungen durchsuchen mit MEMBEROFcdms/suchen/memberof | Wie man findet, in welchen Objekten eine Liste ein bestimmtes Element enthält, und warum MEMBEROF auf einem Nicht-Listenfeld abgelehnt wird. per IDin einer ODER-Gruppekein Listenfeld → 400ungültige UUID → 400 |
| 4.7 Sortierungcdms/suchen/sortierung | Mehrere Sortierkriterien, Richtung ASC/DESC/NONE, Sortieren über Beziehungen und was bei einem falschen Sortierpfad passiert. ASCDESCNONEmehrere Kriterienüber Pfadohne orderKriterium ohne Richtungfalscher Pfad → 400 |
| 4.8 Blättern und Trefferzahlcdms/suchen/blaettern | Wie page, limit und meta zusammenspielen, warum limit: -1 alles liefert und woher totalCount kommt.limit gesetztlimit -1 (alles)limit 0Seite hinter dem Endenegative Seitemetaabstraktes Modell |
| 4.9 Filter in verschachtelten Listencdms/suchen/unterlisten | Wann ein parameter oben steht und wann innerhalb eines response-Eintrags, und was das für die Datenmenge bedeutet.Filter auf die TrefferFilter auf eine Unterlistebeides zusammenUnterliste ohne limit |
| 4.10 Datums- und Zeitwertecdms/suchen/datumswerte | In welchem Format Datum, Uhrzeit und Zeitstempel geschrieben werden und wie Zeiträume gefiltert werden. DatumUhrzeitZeitstempelZeitraumSystemfelder _createdOn, _updatedOnfalsches Format |
| 4.11 Filter, die immer mitlaufencdms/suchen/unsichtbare-filter | Was der Server zu jeder Suche unsichtbar dazunimmt: Besitzer, Attributfilter, eigene Pflichtfilter, und dass der Mandant über die Wahl der Datenbank wirkt. Erklärt, warum zwei Personen verschiedene Treffer sehen. Owner-FilterAttributfiltereigener PflichtfilterMandant über DatenbankAttribut fehlt → 422Pflichtfilter nicht anwendbar → 500 |
| 4.12 Wenn ein Filter nicht passtcdms/suchen/kaputte-filter | Was bei fehlendem Schlüssel, falschem Operator, unpassendem Wert, ungültiger UUID, unbekanntem Feld oder unauflösbarem Pflichtfilter passiert. key/param fehlt → 400ungültige UUID → 400unbekanntes Feld → 400Operator passt nicht zum Feld → 400Feld eines Untertyps → erlaubtWert passt nicht zum Typ → 400Operator unbekannt → 400falsches Sortierfeld → 400parameter null → 400Pflichtfilter unauflösbar → 500 |
5. Daten schreiben
Objekte anlegen und ändern: Create, PUT (ersetzen) und PATCH (ändern), die null-Falle, Defaultwerte, Validierung und was bei gleichzeitigen Änderungen passiert.
| 5.1 Ein Objekt anlegencdms/schreiben/anlegen | Was bei POST /create Schritt für Schritt passiert: Systemfelder, Defaultwerte, Hooks, Validierung, Speichern, Zurücklesen.JSONmit Dateien (Multipart oder Base64)Singletonabstraktes Modell mit @typemit Kindobjektenohne Rolle → 403Regel verletzt → 422response fehlt → 400 |
| 5.2 Ersetzen mit PUTcdms/schreiben/put-ersetzen | PUT beschreibt den vollständigen Zielzustand. Hier steht, was mit fehlenden Feldern, Referenzen und Listen passiert und woher die ID kommt. einfaches Feld fehlt → leerReferenz fehlt → gelöstabhängiges Kind fehlt → gelöschtListe fehlt → geleertKind mit id → verknüpft oder mit ersetztKind ohne id → angelegtID aus data, nicht aus dem Pfadnicht sichtbar → 404 |
| 5.3 Ändern mit PATCHcdms/schreiben/patch-aendern | PATCH ändert nur das Genannte. Hier stehen die drei Zustände jedes Feldes (fehlt, null, Wert) für einfache Felder, Referenzen und Listen. Feld fehlt → unverändertFeld null → geleertWert → gesetztListe [] → geleertTeilliste → ZielzustandKind mit id → nur Gesendetes ändernKind ohne id → angelegtohne id → 400 |
| 5.4 PUT oder PATCH? Die null-Fallecdms/schreiben/put-oder-patch | Welches Verb wofür, und warum ein Formularobjekt mit leeren Feldern bei PATCH alles leert. Formular speichernein Feld ändernFeld bewusst leerentypisiertes Objekt an PATCHgelesenes Objekt zurückschickenanlegen oder ändern? |
| 5.5 Defaultwertecdms/schreiben/defaultwerte | Wann ein Feld beim Anlegen automatisch einen Wert bekommt, welche Arten von Defaults es gibt und was mit einem unbrauchbaren Default passiert. LiteralNOW()LocalDate.NOW(), LocalDateTime.NOW(), LocalTime.NOW()Enum-Vorgabewertnur beim Anlegen, auch für Kinderexplizites null → Defaultnicht bei PUT/PATCHunbrauchbar → verworfen |
| 5.6 Validierungcdms/schreiben/validierung | Welche Regeln an Feldern hängen, wann sie geprüft werden, dass alle Verstöße gesammelt in einer 422 kommen und wie der Pfad eines verschachtelten Fehlers aussieht. Pflichtfeld bei Create/Updatenicht leerLängeMusterMin/MaxZukunft/VergangenheitScope ALWAYS/CREATE/UPDATEPatch prüft nur GesendetesKindobjekteunique (Datenbank) → 409falscher Typ im JSON → 400 invalid-value |
| 5.7 Gleichzeitige Änderungencdms/schreiben/gleichzeitig-aendern | Es gibt kein save und bei normalen Modellen kein optimistisches Locking: die letzte Änderung gewinnt. Nur Datei-Modelle erkennen einen Konflikt.normales Modell: last write winsPATCH statt PUT verkleinert KonflikteDatei-Modell: 409 bei überlappenden AnfragenClient entscheidet create/update anhand der id |
6. Beziehungen und verschachteltes Schreiben
Wie Objekte miteinander verbunden sind und wie man verbundene Objekte im selben Request anlegt, verknüpft, ändert oder entfernt.
| 6.1 Beziehungstypen und Recursive-Flagscdms/beziehungen/beziehungstypen | Die vier Beziehungstypen und die Erlaubnisse CREATE, UPDATE und DELETE, die festlegen, was CDMS über eine Beziehung hinweg tun darf. ONETOONEONETOMANYMANYTOONEMANYTOMANYFlag CREATEFlag UPDATEFlag DELETELesen: Rolle statt FlagRollen für Kinder |
| 6.2 Die vier Fälle beim verschachtelten Schreibencdms/beziehungen/vier-faelle | Ob ein Kindobjekt angelegt, geändert, nur verknüpft oder abgelehnt wird, entscheiden zwei Fragen: Hat es eine id? Ist das passende Flag gesetzt?ohne id + CREATE → anlegenohne id ohne CREATE → 400mit id + UPDATE → mitändernmit id ohne UPDATE → nur verknüpfenunbekannte id → 404Listen bei PATCHRollen der KinderStrict Mode aus |
| 6.3 Listen als Zielzustandcdms/beziehungen/listen-zielzustand | Eine Liste im Payload beschreibt, wie die Liste danach aussehen soll. Hier steht, was mit Mitgliedern passiert, die nicht mehr vorkommen. entfernt mit DELETE-Flag → gelöschtentfernt ohne DELETE-Flag → entkoppeltn:m: Verbindung gelöst, auch mit DELETE-Flagneue Mitgliederleere ListeListe fehlt: PUT vs. PATCHReihenfolgedoppelte Einträge |
| 6.4 Beide Seiten einer Beziehungcdms/beziehungen/beide-seiten | CDMS pflegt die Gegenseite einer Beziehung automatisch. Warum der Client die Rückreferenz nicht mitschicken soll. 1:11:n von der 1-Seite1:n von der n-Seiten:mRückreferenz mitgeschicktPUT ohne die Liste der Gegenseite |
| 6.5 Many-to-Many über eine Verbindungstabellecdms/beziehungen/n-zu-m | Wie n:m-Beziehungen über ein eigenes Verbindungsmodell abgebildet werden und was das beim Schreiben bedeutet. MANYTOMANY mit generierter Verbindungstabelleeigenes Verbindungsmodell mit zwei n:1Verbindung anlegenVerbindung entfernenein Ende löschen |
| 6.6 Zyklusschutzcdms/beziehungen/zyklusschutz | Wie CDMS verhindert, dass sich verschachteltes Lesen oder Schreiben im Kreis dreht. Lesen: so tief wie die responseLesen: A → B → AWildcards bleiben bei der idSchreiben: Rückreferenz wird übersprungenSchreiben: jedes Objekt einmalinternes Feld _reference |
7. Daten löschen
Wie ein Objekt gelöscht wird, was mit abhängigen Objekten und Dateien passiert und was danach noch übrig ist.
| 7.1 Der Ablauf eines DELETEcdms/loeschen/loeschablauf | Sichtbarkeit prüfen, laden, Rollen prüfen, Kaskade, Hooks, entfernen: die Schritte eines Löschvorgangs und die Fehler an jeder Stelle. Es gibt nur hartes Löschen. normales ModellSingletonabstraktes Modellunsichtbar → 404ohne Löschrolle → 403zweimal löschen |
| 7.2 Abhängige Objekte (Kaskaden)cdms/loeschen/kaskaden | Wann Kinder mitgelöscht und wann nur abgekoppelt werden, dass jedes Kind seine eigene Löschrolle braucht und dass eine fehlende Rolle alles zurückrollt. mit DELETE-Flag → mitgelöschtohne DELETE-Flag → abgekoppeltje Beziehungstyp: 1:1, 1:n, n:1, n:m, Verbindungsmodellüber mehrere StufenRolle fehlt irgendwo → alles zurückFeldrolle statt Klassenrolle |
| 7.3 Löschen durch Änderncdms/loeschen/indirekt-loeschen | Ein PUT oder PATCH, das ein abhängiges Kind aus einer Liste oder einer Referenz entfernt, löscht es. Hier steht, wann das passiert. PUT: Liste fehlt → alle abhängigen Kinder gelöschtPUT/PATCH: Kind fehlt in der Liste → gelöschtPATCH: Liste fehlt → unverändertEinzelreferenz null → gelöschtohne DELETE-Flag → nur abgekoppeltRollen und Hooks |
| 7.4 Datei-Modelle löschencdms/loeschen/dateien-loeschen | Beim Löschen eines Datei-Modells verschwinden der Datensatz, der Dateiinhalt und alle aufbewahrten Versionen. Die Historie des Datensatzes bleibt, der Inhalt nicht. direkt gelöschtmitgelöscht über DELETE-Flag (1:1, 1:n)durch PUT/PATCH aus dem Elternobjekt entferntgeteilte Datei (n:1, n:m) → bleibtalle Versionen weg |
| 7.5 Was nach dem Löschen bleibtcdms/loeschen/was-bleibt | Die Historie bleibt lesbar, einen Papierkorb (Soft-Delete) gibt es nicht, und ein Rollback holt gelöschte Objekte nicht zurück. Historie lesbarkein Soft-Deletekein Wiederbeleben per Rollbacknicht auditiertes Modell → nichts bleibtneu anlegen aus der Historie |
8. Transaktionen und Konsistenz
Wann Änderungen endgültig sind: ein Request ist eine Transaktion, Commit vor der Antwort, und wo die Atomarität endet.
| 8.1 Ein Request, eine Transaktioncdms/transaktionen/ein-request | Alles in einem Request gelingt oder nichts. Hier steht, wann committet und wann zurückgerollt wird, und dass es zwischen zwei Requests keine Klammer gibt. Erfolg → Commit vor der AntwortFehler irgendwo → RollbackKonflikt beim Commit → 409zwei Requests → zwei TransaktionenHooks in der Transaktion, Seiteneffekte nicht |
| 8.2 Anlegen und Zurücklesen: STRICT oder LENIENTcdms/transaktionen/anlegen-und-zuruecklesen | Nach einem Create liest CDMS das Objekt für die Antwort zurück. Was passiert, wenn das Zurücklesen scheitert, entscheidet der CreateReadMode. STRICT (Standard): alles zurückLENIENT: angelegt, 200 mit Hinweis und idpro Request überschreibbarEinstellung der InstallationSingletons: immer STRICT |
| 8.3 Keine Atomarität über zwei Datenbankencdms/transaktionen/datenbankgrenzen | Eine Änderung, die System-DB und Mandanten-DB berührt, ist nicht atomar. Hier steht, wann das vorkommt und was es bedeutet. normale Anfrage: eine DatenbankHook oder eigener Code schreibt beide EbenenFehler vor dem Commit → beide zurückFehler beim Commit → Teilzustand möglichBetriebsart SINGLE |
| 8.4 Dateien und Transaktioncdms/transaktionen/dateien-und-transaktion | Dateiinhalte werden während der Anfrage nur vorbereitet und erst nach dem Commit wirksam. Scheitert die Anfrage, bleibt der Dateispeicher, wie er war. ErfolgFehler beim Vorbereiten der DateiFehler nach dem VorbereitenFehler nach dem CommitLöschen |
| 8.5 Darf der Client wiederholen?cdms/transaktionen/wiederholen | Welche Operationen gefahrlos wiederholt werden können und bei welchen eine Wiederholung ein zweites Objekt erzeugt. GET/POST read, queryPUTPATCHDELETEPOST createRollbacknach 401nach 4xxnach 5xxkeine Antwort |
9. Dateien
Dateien hochladen, herunterladen, ersetzen und versionieren: wo die Bytes liegen, wo die Metadaten, und wie beides zusammenbleibt.
| 9.1 Was ein Datei-Modell istcdms/dateien/datei-modell | Metadaten in der Datenbank, Inhalt im Dateispeicher. Hier steht, wer welchen Teil verwaltet. eigenständiges Datei-ModellDatei als Kind eines anderen ModellsFelder, die der Server setztEndpunkte |
| 9.2 Hochladencdms/dateien/hochladen | Die zwei Wege Multipart und Base64, die passenden Endpunkte und wie Dateiteil und Datei-Objekt über den Namen zusammenfinden. POST /create/uploadPUT /update/{id}/uploadPATCH /update/{id}/uploadBase64 im JSONmehrere Dateien in einem RequestName passt nicht → 400doppelte Namen → abgelehnt |
| 9.3 Herunterladencdms/dateien/herunterladen | Wie GET /{id}/file funktioniert, warum das Token hier in der URL steht und welche Rechte und Grenzen gelten.normales Datei-Modell: GET /{id}/fileSingleton: GET /fileaccess_token in der URLPrüfungen: Token, Lesen, Download-RolleAntwort-Header |
| 9.4 Ersetzen und Umbenennencdms/dateien/ersetzen-umbenennen | Was ein Update mit und ohne neue Datei bewirkt: Inhalt ersetzen, nur umbenennen, oder beides. mit neuer Datei → Inhalt ersetztohne Datei → Inhalt bleibtnur umbenennenumbenennen und ersetzenPUT und PATCHgleichzeitig → 409 |
| 9.5 Dateiversionencdms/dateien/versionen | Bei auditierten Datei-Modellen bleibt jeder alte Stand erhalten. Wie die Versionen abgelegt werden, wie Revision und Inhalt zusammenhängen und wann einfach überschrieben wird. auditiert → Versionennicht auditiert → überschriebenRevision und Version gehören zusammenZugriff nur über RollbackAuditing nachträglich einschaltenkein automatisches Aufräumen |
| 9.6 Ablage und Mandantentrennung im Speichercdms/dateien/ablage | Wie der Speicherpfad aufgebaut ist, wie Mandanten im Dateisystem getrennt sind und wie eine Datei atomar abgelegt wird. MULTI: Pfad mit MandantSINGLESystem-Modell ohne MandantMandant fehlt → abgelehntatomares AblegenVerzeichnisrechte |
| 9.7 Größengrenzencdms/dateien/grenzen | Welche Größengrenzen für Uploads und Downloads gelten, was bei einer Überschreitung passiert und wo man sie einstellt. Upload: 25 MB je Datei, 500 MB je Request, 500 Teilegleiche Grenzen für Multipart und Base64413 mit der Grenze im messageKeyEinstellung über Standard-PropertiesProxy und Ingress davorDownload: ganze Datei im Arbeitsspeicherharte Grenze 2 GiBkein Kontingent je Mandant |
| 9.8 Speicher-Backendscdms/dateien/speicher-backends | Wo die Dateiinhalte liegen: lokales Dateisystem oder Volume, und Anwendungen ganz ohne Dateispeicher. FILESYSTEM: lokales Dateisystem / VolumeNONE: kein DateispeicherStartprüfung des BasisverzeichnissesHealth-CheckBetrieb im Container |
10. Sicherheit von Daten
Wer was sehen und ändern darf: Rechte auf Modell, Beziehung und Zeile, eigene Daten, Attributfilter, warum Unsichtbares 404 liefert und wie Strict Mode Fehler behandelt.
| 10.1 Die drei Ebenen im Überblickcdms/sicherheit/drei-ebenen | Modell (darf ich diese Operation?), Beziehung (darf ich über dieses Feld?) und Zeile (darf ich dieses Objekt?). Wie die Ebenen hintereinander greifen. Lesen und SuchenÄndern und LöschenAnlegenverschachtelte Anfrage |
| 10.2 Modellrollencdms/sicherheit/modellrollen | Welche Rolle eine Operation verlangt: Basisrolle, Rolle je Aktion, Endpunkt-Rolle, öffentlicher Zugriff. PATCH nutzt die Update-Rolle. Basisrolle erlaubt allesAktionsrolle ersetzt die BasisrolleEndpunkt-RollepublicAccesshistory, rollback, downloadabstraktes Modell |
| 10.3 Wie Rollennamen entstehencdms/sicherheit/rollennamen | Aus dem API-Pfad /audit/question wird audit-question, daraus audit-question-read. Die Regel an Beispielen.BasisrolleAktionsrolleFeldrolleModell ohne Ordnerverschachtelte Ordner, Leerzeichen, CamelCaseeigener Name aus der Modelldatei |
| 10.4 Rechte auf Beziehungen (Feldrollen)cdms/sicherheit/feldrollen | Eine Feldrolle an einer Beziehung erlaubt, ein Kindmodell über genau ein Feld zu lesen oder zu schreiben, ohne direkten Zugang zum Kindmodell. An einfachen Feldern wirkt eine Rolle anders: als zusätzliche Bedingung. Feldrolle statt Klassenrollenur über dieses Feldkein direkter Endpunktnur eine Stufe, nur diese Operationan einfachen Feldern: zusätzliche Bedingung |
| 10.5 Geschützte Werte (Rollen an einfachen Feldern)cdms/sicherheit/geschuetzte-werte | Eine Rolle an einem einfachen Feld schützt einen einzelnen Wert. Wer sie nicht hat, sieht das Feld nicht, kann es nicht ändern und nicht danach suchen. Das Modell selbst bleibt lesbar. zusätzlich zur ModellrolleWildcard lässt weg, Name wird abgelehntgeprüft wird die ÄnderungLeeren braucht die LöschrollePUT ohne Wert lässt stehenFilter und Sortierung brauchen die Leserolle |
| 10.6 Verschlüsselte Feldercdms/sicherheit/verschluesselte-felder | Ein Textfeld mit der Regel „verschlüsselt“ steht verschlüsselt in der Datenbank und kommt entschlüsselt zurück. Was du dafür einstellst, wie ein Schlüsselwechsel geht und was mit dem Feld nicht geht. Anlegen und Ändern: verschlüsselt speichernLesen, Suchen, Historie: entschlüsselt ausliefernSchlüssel und frühere SchlüsselWerte, die noch im Klartext stehenFilter und Sortierung abgelehntnicht zusammen mit „eindeutig“ |
| 10.7 Nur die eigenen Daten (Owner-Filter)cdms/sicherheit/eigene-daten | Bei Benutzer-Modellen sieht jede Person nur ihre eigenen Zeilen. Wie _userId gesetzt und geprüft wird.AnlegenLesenSuchenÄndern und Löschenmitangelegte KinderTechnischer Client ohne Personim Auftrag einer anderen Person |
| 10.8 Attributfiltercdms/sicherheit/attributfilter | Ein Attribut der Person (z. B. projects) schränkt ein Datenfeld ein. Wie EQ/IN entsteht, was * bedeutet, was bei fehlendem Attribut passiert und was für Personen mit mehreren Mandanten gilt.ein Wert → EQmehrere Werte → IN* → unbeschränktfehlt/leer → 422Feld über eine Beziehungmehrere Attributfilter an einem ModellPerson mit mehreren Mandanten |
| 10.9 Eigene Datenfiltercdms/sicherheit/eigene-filter | Wie ein Projekt eigene Sichtbarkeitsregeln einbaut und warum ein Pflichtfilter, der nicht aufgelöst werden kann, die Anfrage abbricht statt still zu verschwinden. Filter liefert eine BedingungFilter liefert null → keine EinschränkungFilter wirft einen Fehler → Anfrage scheitertmehrere Filter an einem Modellunauflösbar → 500 |
| 10.10 Warum Unsichtbares 404 liefertcdms/sicherheit/unsichtbar-ist-404 | Ein Objekt, das man nicht sehen darf, gibt es aus Sicht des Aufrufers nicht. Das gilt auch beim Ändern und Löschen: Man kann nur schreiben, was man lesen kann. LesenSuchenReferenzen und Listen in der responseÄndernLöschenRollbackHerunterladen |
| 10.11 Strict Mode: Fehler oder still ignorierencdms/sicherheit/strict-mode | Ob eine unzulässige Anfrage einen Fehler liefert oder still gekürzt wird. Wo das wirkt und warum strikt der Standard ist. strikt: fehlende Rolle → 403tolerant: Read → 404, Query → 403tolerant: Schreiben → 403 mit eigenem Schlüsseltolerant: Referenz in der response → nullverschachteltes Create strikt/tolerantnur global einstellbar |
| 10.12 Zugriff ohne Tokencdms/sicherheit/ohne-token | Was eine Anfrage ohne Token erreicht: offene Pfade, Endpunkte ohne Rolle, und wie ein ungültiges Token behandelt wird. kein Token → 403ungültiges, abgelaufenes oder fremdes Token → 401offene Pfade ohne TokenEndpunkt ohne Rolle (publicAccess)Token in der URL beim Download |
11. Mandantentrennung in CDMS
Wie CDMS Kunden voneinander trennt: eine Datenbank pro Mandant, woher der Mandant einer Anfrage kommt, wie er gewechselt wird und welche Regeln nie gebrochen werden.
| 11.1 SINGLE und MULTIcdms/mandanten/single-multi | Die zwei Betriebsarten der Datenhaltung: eine Datenbank für alle oder eine pro Mandant. Was sich dadurch ändert. SINGLEMULTIBetriebsart fehlt → Start scheitertalter und neuer Schlüssel widersprechen sich → Start scheitertBetriebsart später wechseln |
| 11.2 Woher der Mandant einer Anfrage kommtcdms/mandanten/woher-mandant | Der Mandant steht im Token. Hier steht, wie er gelesen wird und was ohne Mandant passiert. aus der Organisation im Tokenaus dem Attribut tenantAuswahl unter mehreren Organisationenmehrere Organisationen ohne Auswahl → 403Organisation und Attribut widersprechen sich → 403kein Mandant in MULTI → 403, dahinter 400SINGLE ignoriert ihn |
| 11.3 Welche Datenbank? Das Persistenzzielcdms/mandanten/welche-datenbank | Die Entscheidung, ob ein Zugriff in der System-DB oder in der Mandanten-DB landet, als vollständige Entscheidungstabelle. Ohne Rückfall auf die System-DB. System-ModellMandanten-Modell mit Mandantohne Kontext → 500ohne Mandant → 400Mandant nicht erlaubt → 403Betriebsart SINGLEDatenbank fehlt oder ist nicht erreichbar |
| 11.4 Mandantenwechsel per Headercdms/mandanten/mandantenwechsel | Wie eine berechtigte Person mit dem Header tenant für einen anderen Mandanten arbeitet und warum ein Wechsel ohne Rolle still ignoriert wird.Auswahl unter eigenen Organisationenprivilegierter Wechselohne Rolle → still ignoriertZiel nicht erlaubt → 403Ziel gesperrt → 403Betriebsart SINGLE |
| 11.5 Benutzerwechsel per Headercdms/mandanten/benutzerwechsel | Wie eine berechtigte Person im Namen einer anderen Person arbeitet, mit den eigenen Rollen oder mit denen der Zielperson, und welche Prüfungen davor stehen. mit Rolle, eigene Rollenmit Rolle, Rollen der Zielpersonohne Rolle → abgelehntZielperson unbekannt oder nicht im Mandanten → abgelehntNachschlagen nicht möglich → abgelehntungültiger Wert in user-roles → abgelehntohne Freigabe der Zielperson → abgelehntFreigabe für eigene Rollen, target verlangt → abgelehntFreigabe in einem anderen Mandanten → abgelehntFreigabe widerrufen → ab der nächsten Anfrage abgelehntDienstkonto eines freigestellten ClientsFreigabe abgeschaltet (consent=off)Freigabe beantragen, bestätigen, direkt erteilen, widerrufenwas wechselt und was bleibtAnlegenHistoriezusammen mit einem MandantenwechselBetriebsart SINGLE |
| 11.6 Wird der Mandant bedient?cdms/mandanten/mandant-bedient | Vor jedem Zugriff fragt die Filterkette bei CIAS nach, ob der Mandant aktiv ist. Hier steht die Sicht von CDMS; die Einzelheiten stehen bei CIAS. aktivgesperrt, geschlossen oder außerhalb der GültigkeitunbekanntCIAS nicht erreichbarnach einem MandantenwechselAnfrage ohne MandantBetriebsart SINGLE |
| 11.7 Datenbanken, Pools, Migrationcdms/mandanten/datenbanken-pools | Jeder Mandant hat eine eigene Datenbank mit eigenem Verbindungspool. Wann sie angelegt und wie ihr Schema migriert wird. Anlage bei ProvisionierungAnlage beim ersten ZugriffDatenbank fehlt ohne Freigabe → 500Server nicht erreichbar → 503Migration pro MandantPool pro ZielRäumen ungenutzter Mandanten |
| 11.8 Regeln, die nie gebrochen werdencdms/mandanten/invarianten | Die Sicherheitsinvarianten der Mandantentrennung: kein Rückfall auf die System-DB, getrennte Typmengen, nur drei Stellen dürfen einen Mandanten setzen. |
12. Audit, Historie, Rollback
Wie jede Änderung nachvollziehbar bleibt: Revisionen, Historie lesen, auf einen alten Stand zurücksetzen, und was dabei mit Dateien und Beziehungen passiert.
| 12.1 Was auditiert wirdcdms/audit/was-auditiert | Welche Modelle eine Historie haben, welche Operationen eine Revision erzeugen und welche Revisionsarten es gibt. auditing: trueADDMODDELnicht auditiertes Modell |
| 12.2 Was eine Revision festhältcdms/audit/revisionsdaten | Nummer, Zeitpunkt, Person, IP-Adresse, Browser, und dass es pro Datenbank ein eigenes Revisionsprotokoll gibt. RevisionsnummerZeitpunktPerson (ID und Name)handelnde Person bei einem BenutzerwechselIP-AdresseUser-AgentÄnderung ohne Benutzerein Revisionsprotokoll je Datenbank |
| 12.3 Historie lesencdms/audit/historie-lesen | Wie POST /{id}/history Revisionen seitenweise liefert, welche Rechte nötig sind und warum auch gelöschte Objekte eine Historie haben.normales ModellSingletongelöschtes Objektohne History-Rolle → 403unsichtbares Objekt → 404unbekannte id → leere Liste (Modell ohne Filter)blättern mit page und limit |
| 12.4 Auf einen alten Stand zurücksetzencdms/audit/rollback | Ein Rollback erzeugt eine neue Revision mit dem alten Inhalt. Was zurückkommt (eigene Felder, Einzelreferenzen) und was nicht (Listen, gelöschte Objekte). einfache FelderEinzelreferenzenListen (nicht)gelöschtes Objekt (nicht)fremde Revision → abgelehntSingleton |
| 12.5 Rollback bei Dateiencdms/audit/rollback-dateien | Wie der Dateiinhalt beim Rollback zurückkopiert wird und warum der aktuelle Stand vorher gesichert wird. Inhalt kommt mit dem Datensatz zurückaktueller Inhalt wird vorher als Version gesichertRollback eines RollbacksRevision ohne fileVersion → Inhalt bleibtgleicher Inhalt wie jetztName, Größe und Typ |
| 12.6 Audit ist nicht dasselbe wie Systemfeldercdms/audit/audit-und-systemfelder | Der Unterschied zwischen _createdOn am Objekt und der Revisionsgeschichte._createdOn_updatedOn_userIdHistorienicht auditiertes Modell |
| 12.7 Datenschutz und Aufbewahrungcdms/audit/datenschutz | Welche personenbezogenen Daten im Audit stehen und wie lange Revisionen aufbewahrt werden. Daten über die handelnde PersonDaten im Objektinhaltnach dem Löschen des ObjektsAufbewahrung ohne Ablaufdatumwer die Historie lesen darf |
13. Eigene Fachlogik einhängen
Wie Projektlogik in die Standardabläufe kommt, ohne generierten Code zu ändern: Hooks, ihre Reihenfolge, ihr Verhalten bei Fehlern und bei verschachtelten Objekten.
| 13.1 Hooks: Arten und Zeitpunktecdms/erweitern/hooks | Welche Hook-Punkte es gibt (vor und nach der Datenbankänderung, je Operation) und wie ein Hook registriert wird. CREATEUPDATEPATCHDELETEROLLBACKREAD (nach dem Laden, vor der Antwort)beforeafterReihenfolge per @OrderModell-Hook und Feld-Hook |
| 13.2 Feld-Hookscdms/erweitern/feld-hooks | Wiederverwendbare Logik für einen einzelnen Wert: verschlüsselt speichern, ausrechnen, vereinheitlichen. Wie ein Feld-Hook aussieht, wie du ihn einem Feld zuordnest und wann er läuft. vor dem Schreiben (beforeDatabaseChange)nach dem Lesen (afterDatabaseRead)umwandelnder Hookableitender Hook (runsOnEveryWrite)mehrere Hooks an einem FeldPATCH, PUT mit Feldrolle, ROLLBACKnicht durchsuchbar (keepsValueSearchable) |
| 13.3 Die Reihenfolge in einem Schreibvorgangcdms/erweitern/hook-reihenfolge | Rekursion, Before-Hooks, Validierung, Speichern, After-Hooks. Warum ein Before-Hook ein Pflichtfeld noch füllen darf. Create, PUT, PATCHDELETEROLLBACKBefore-Hook füllt ein PflichtfeldBefore-Hook setzt einen unzulässigen WertBefore-Hook ändert ein gültiges Feld |
| 13.4 Hooks bei verschachtelten Objekten und Kaskadencdms/erweitern/hooks-verschachtelt | Hooks feuern auch für Kinder und kaskadiert gelöschte Objekte. Wie sie gesammelt und in welcher Reihenfolge ausgeführt werden, und wann keine Hooks feuern. Kind angelegtKind geändertKind kaskadiert gelöschtKind nur entkoppelt (kein Hook)Kind nur verknüpft (kein Hook)Reihenfolge: Operationen, Eltern und KinderREAD-Hooks für ausgebaute Referenzen |
| 13.5 Ein Hook schreibt selbstcdms/erweitern/hook-schreibt-selbst | Legt ein Hook über einen System-Layer selbst etwas an, ist das ein Schreibvorgang im Schreibvorgang. Jeder bekommt seine eigene Ebene: eigene Prüfung, eigene Hooks, ein gemeinsamer Commit. Die Tiefe ist begrenzt und messbar. Hook legt einen gültigen Datensatz anäußerer Datensatz ist ungültiginnerer Datensatz ist ungültigAfter-Hooks beider Ebeneninnerer Create mit LENIENTHook schreibt bei jedem Schreiben (zu tief)Maximaltiefe einstellenTiefe im Monitoring |
| 13.6 Wenn ein Hook scheitertcdms/erweitern/hook-fehler | Ein Fehler im Hook rollt den ganzen Request zurück. Wie der Fehler beim Client ankommt. Before-Hook wirftAfter-Hook wirftREAD-Hook wirftHookValidationException → 422HookExecutionException → 500andere Exception → 500 |
14. Fehler verstehen
Wie Fehler aussehen, welcher Statuscode was bedeutet und wie man 401, 403 und 404 auseinanderhält.
| 14.1 Das Fehlerformatcdms/fehler/fehlerformat | Welche Felder eine Fehlerantwort hat und worauf ein Client verzweigen soll. Fehlerantwort von CDMSValidierungsfehler mit violationsAblehnung der FilterketteAntwort ohne KörperStatus 200 in Fehlerform (LENIENT) |
| 14.2 Landkarte der Statuscodescdms/fehler/statuscodes | Jeder Statuscode mit den Situationen, in denen CDMS ihn liefert: 200, 400, 401, 403, 404, 409, 413, 422, 500, 503. 200 (auch LENIENT-Sonderfall)400401403404409413422500503 |
| 14.3 401, 403 oder 404?cdms/fehler/401-403-404 | Die drei Codes, die am häufigsten verwechselt werden, als Entscheidungsweg: Wann erneuern, wann aufgeben, wann ist das Objekt unsichtbar. 401: Token ungültig oder abgelaufen403 ohne Token403 der Mandantenprüfung403: Rolle fehlt404: Objekt fehlt oder unsichtbar404: Pfad unbekanntReihenfolge von Rolle und Sichtbarkeit |
| 14.4 Validierungsfehler ins Formular bringencdms/fehler/validierung-ins-formular | Wie ein Client die gesammelten Verstöße einer 422 den Formularfeldern zuordnet, auch bei verschachtelten Pfaden. einfaches FeldFeld in einer EinzelreferenzFeld in einer ListeFeld, das das Formular nicht zeigtunbekannte Regel400 invalid-value mit PfadFehler ohne Feldbezugüber einen BFF |
CIAS – Identität und Zugang
Die Brücke zwischen einer CodamAI-Anwendung und dem Identity Provider (Keycloak). CIAS weiß, wer eine Person ist, zu welchem Mandanten sie gehört, welche Rollen es gibt und wer sie vergeben darf. Das Anmelden selbst übernimmt Keycloak.
1. Grundlagen: was CIAS ist und was nicht
Die Begriffe und die Aufteilung, ohne die kein CIAS-Ablauf verständlich ist: die Objekte und ihre Eigentümer, Mandant und Gruppe, die zwei Rechte-Matrizen, die Schreibrichtung und die Obergrenze.
| 1.1 CIAS als Brücke zum Identity Providercias/grundlagen/bruecke | Was CIAS tut und was ausdrücklich nicht: kein Login, keine Passwörter, keine Prüfung von Rechten auf Daten. Mit der Tabelle „CIAS tut / CIAS tut nicht“. Was Keycloak machtWas CIAS machtWas die Anwendung machtSchreibrichtung Anwendung → CIAS → KeycloakLeserichtung: Keycloak führt bei Konteneingebettet / getrennt |
| 1.2 Die Objekte und wem sie gehörencias/grundlagen/objekte | Benutzer, Mandant, Rolle, Rollenvergabe, Gruppe, Attribut, Modul: was jedes Objekt ist, wer es besitzt und was Keycloak davon als Kopie hält. BenutzerMandantRolleRollenvergabeGruppeBenutzerattributProfilattributModul |
| 1.3 Mandant, Organisation, Gruppecias/grundlagen/mandant-organisation-gruppe | Zwei Strukturbegriffe, nicht drei. Der Mandant trennt Daten, die Gruppe bündelt Rollen, „Organisation“ ist nur Keycloaks Name für einen dynamischen Mandanten. Mit der einen Frage, die entscheidet, und einem durchgespielten Szenario. MandantOrganisation (nur Keycloak)GruppeEltern-/Kind-Struktur (bewusst nicht) |
| 1.4 Die zwei Rechte-Matrizencias/grundlagen/zwei-matrizen | Wie ein Recht getragen wird (Realm-Rolle, Client-Rolle, Organisationsrolle, Gruppe, Attribut) ist CIAS. Was ein Recht erlaubt (Modell, Operation, Feld) ist CDMS. Warum CIAS keine Modell-Operations-Matrix hält. Matrix A: Träger eines RechtsMatrix B: Inhalt eines Rechts |
| 1.5 Die Obergrenze: niemand vergibt mehr, als er hatcias/grundlagen/obergrenze | Die Regel über allen Schreibwegen: Eine Vergabe übersteigt nie den Vergebenden. Was sie für Rollen, Gruppen und Attribute bedeutet und wie sie sich von der Delegation unterscheidet. RollenGruppen (über ihre Rollen)Attribute (Wertebereich)platform-admin |
2. Login und Token
Wie eine Person oder ein Dienst an ein Token kommt, wie es erneuert und beendet wird und was bei jeder Anfrage mit dem Token passiert.
| 2.1 Anmelden im Browsercias/login/browser-login | Der Weg von „Seite öffnen“ bis „angemeldet“ über Keycloak mit Authorization Code, mit allen Varianten der Login-Seite. nicht angemeldet → Weiterleitungautomatischer Loginnach Abmeldung (kein Auto-Login)Rücksprung nur auf interne PfadeKeycloak-Seiten: Passwort, OTP, Passwort vergessen |
| 2.2 Anmelden als Dienst (Client Credentials)cias/login/dienst-login | Wie ein Server ohne Person ein Token bekommt, wofür das gedacht ist und warum benutzereigene Modelle damit meist nichts liefern. Client CredentialsCIAS an der Keycloak-Admin-APIDienst fragt CIAS (Lookup) |
| 2.3 Sitzung im BFF und Cookiescias/login/bff-sitzung | Warum das Token im Server des Frontends liegt und nicht im Browser, wie das Sitzungs-Cookie aussieht und warum jedes Portal ein eigenes Cookie-Präfix hat. Cookie httpOnly, sameSite=laxeigenes Präfix je PortalLaufzeit 1 h |
| 2.4 Token erneuerncias/login/token-erneuern | Wann und wie das Token vor Ablauf erneuert wird und was bei einem abgelehnten oder gescheiterten Refresh passiert. Refresh erfolgreichRefresh abgelehnt (4xx) → neu anmeldenKeycloak nicht erreichbar (5xx) → später erneut |
| 2.5 Abmeldencias/login/abmelden | Wie die Abmeldung Cookies löscht, Keycloak die Sitzung beendet und die Login-Seite danach nicht sofort wieder anmeldet. mit ID-Tokenohne ID-Token (Bestätigungsseite)ohne konfigurierten Keycloak (nur lokal) |
| 2.6 Was bei jeder Anfrage mit dem Token passiertcias/login/token-pruefung | Die Filterkette Schritt für Schritt: Header lesen, prüfen, tauschen, Identität lesen, Mandant auflösen, Mandant zulassen, Rollen bilden, Wechsel ausführen, aufräumen. gültiges Tokenkein Token → 403ungültiges, abgelaufenes oder fremdes Token → 401Token-Tausch abgelehnt → 401Keycloak nicht erreichbar → 503MULTI ohne Mandant → 403Mandant nicht eindeutig oder nicht bedient → 403Benutzerwechsel abgelehnt → 403SINGLE: Mandant im Token zählt nicht |
| 2.7 Token-Tausch (Token-Exchange)cias/login/token-exchange | Warum CIAS jedes Benutzer-Token gegen eines für den eigenen Client tauscht, wie lange das Ergebnis gemerkt wird und was bei falsch konfiguriertem Realm passiert. Tausch mit Cache-TrefferTausch ohne CacheToken ohne jti (kein Cache)Realm falsch konfiguriert → 401Keycloak nicht erreichbar → 503 |
| 2.8 Was aus dem Token gelesen wirdcias/login/claims | Welcher Claim wohin im RequestContext wandert: Benutzer, Name, Realm-Rollen, Fachrollen, Organisation, Mandant, erlaubte Mandanten, Attribute. Benutzer und NameRealm-Rollen und FachrollenGruppenOrganisation und Mandanterlaubte MandantenAttributeProtokoll-Claims (werden nicht gelesen) |
| 2.9 Effektive Rollen: global oder im Mandantencias/login/effektive-rollen | Wie CIAS aus globalen Rollen und Rollen der Organisation die gültigen Rollen bildet und warum global vergebene Rollen unter einem dynamischen Mandanten wegfallen können. nur globale RollenOrganisation ohne eigene RollenOrganisation mit eigenen Rollen (ersetzt)Realm-Rollen (immer)Benutzerwechsel mit Rollen der Zielperson |
| 2.10 Warum ein Rechteentzug verzögert wirktcias/login/rechteentzug-verzoegert | Entzogene Rechte stehen noch im Token, bis es abläuft oder der Tausch-Cache verfällt. Wie lange das dauert und wie man sofort sperrt. Rolle entzogenAttributwert pro Mandant geändertMandant gesperrtKonto gesperrt |
3. Registrierung
Wie aus einer Person ein Benutzer wird: ein Ablauf mit vier Varianten, E-Mail-Bestätigung, Passwort bei Keycloak, Freigabe, Mandantenzuordnung, Startrollen, Hooks und Mails.
| 3.1 Ein Ablauf, vier Variantencias/registrierung/ueberblick | Selbstregistrierung, Anlage durch den Plattform-Administrator, Einladung durch den Mandanten-Administrator und das Einlösen der Einladung: was gleich ist, was sich unterscheidet. SELF_SERVICEPLATFORM_ADMINTENANT_ADMINEinladung einlösenneue Adresse / bekannte Adressemit / ohne Freigabe |
| 3.2 Die Zustände einer Registrierungcias/registrierung/zustaende | Von INITIATED bis COMPLETED: jeder Zustand, jeder Übergang, und woher EXPIRED und FAILED kommen. INITIATEDPENDING_VERIFICATIONVERIFIEDPENDING_APPROVALAPPROVEDREJECTEDPROVISIONINGCOMPLETEDFAILEDEXPIRED |
| 3.3 Selbstregistrierungcias/registrierung/selbstregistrierung | Eine Person registriert sich ohne Anmeldung über das öffentliche Formular. Der vollständige Ablauf mit Freigabe und neuem Mandanten. neue AdresseAdresse schon bekanntmit Freigabeohne Freigabeneuer Mandant (CREATE_NEW)ohne Mandant (NONE) |
| 3.4 Anlage durch den Plattform-Administratorcias/registrierung/admin-anlage | Der Plattform-Administrator legt eine Person an und darf als Einziger den Mandanten im Payload nennen. mit Mandant aus dem Payload (FROM_PAYLOAD)ohne Mandant (NONE)Ablauf nicht konfiguriert → abgelehnt |
| 3.5 Einladung durch den Mandanten-Administratorcias/registrierung/einladung | Ein Mandanten-Administrator lädt eine Person in den eigenen Mandanten ein. Der Mandant kommt immer aus seinem Token, nie aus dem Payload. neue PersonPerson hat schon ein Konto (Beitritt)Mandant im Payload (wird ignoriert)Aufrufer ohne Mandant → 403 |
| 3.6 Eine Einladung einlösencias/registrierung/einladung-einloesen | Was die eingeladene Person sieht und tut: offene Felder abrufen, Link einlösen, Mitgliedschaft. offene Felder abrufenannehmenschon angenommen (gleiche Antwort)Link unbekannt oder abgelaufen → 404 |
| 3.7 Die E-Mail ist das Kontocias/registrierung/bestehendes-konto | Ein Konto pro Adresse, beliebig viele Mandanten. Was passiert, wenn sich eine bekannte Adresse registriert, und warum niemand ohne Zustimmung einem Mandanten hinzugefügt wird. NEW_ACCOUNTADDITIONAL_MEMBERSHIPbekannt ohne Mandant → „bereits registriert“abgebrochenes Konto wird übernommengesperrtes Konto bleibt gesperrtälterer offener Versuch wird ersetzt |
| 3.8 E-Mail bestätigencias/registrierung/email-bestaetigen | CIAS legt das Konto deaktiviert an, verschickt eine eigene Mail mit Einmal-Link und schaltet erst nach dem Klick frei. Wie der Link geschützt ist. Klickzweiter Klick (gleiches Ergebnis)Link unbekannt oder abgelaufen → 404Admin bestätigt manuell |
| 3.9 Das Passwort setzencias/registrierung/passwort-setzen | CIAS sieht nie ein Passwort. Wie die Person nach der Bestätigung ihr Passwort bei Keycloak setzt und was ohne Passwort-Setz-Link passiert. mit Setz-Link in der Willkommensmailohne Link („Passwort vergessen“)Link später per Admin |
| 3.10 Freigabe durch einen Administratorcias/registrierung/freigabe | Wenn eine Registrierung freigegeben werden muss: genehmigen, ablehnen, wiederholen, verwerfen. genehmigenablehnen (Mail REJECTED)Bereitstellung wiederholenverwerfen (unbenutztes Konto wird gelöscht)Liste der Registrierungen |
| 3.11 Woher der Mandant kommtcias/registrierung/mandant-zuordnen | Die sechs Arten der Mandantenzuordnung und die Reihenfolge, in der Policy und Hook entscheiden. NONECREATE_NEWJOIN_EXISTINGFROM_CALLERFROM_PAYLOADFROM_INVITATIONHook überschreibt |
| 3.12 Was beim Abschluss passiertcias/registrierung/bereitstellung | Die Bereitstellung in fester Reihenfolge: Startrollen bestimmen, Konto freischalten, Mandant anlegen oder zuordnen, Rollen vergeben, Willkommensmail. neuer Mandantbestehender Mandant (statisch)bestehender Mandant (dynamisch)ohne MandantFehler → FAILED |
| 3.13 Startrollen als Regelwerkcias/registrierung/startrollen | Welche Rollen eine neue Person bekommt, entscheidet ein Regelwerk je Situation (Gründer, Mitglied, ohne Mandant). Wer Regeln schreiben darf und warum die Mandantenregel ersetzt statt ergänzt. TENANT_FOUNDERTENANT_MEMBERTENANTLESSGrundeinstellung der Installation (Bean)Regel der InstallationRegel des Mandanten (ersetzt)Delegation beim Anwenden erneut geprüft |
| 3.14 Eigene Logik: Hooks und Eventscias/registrierung/hooks-events | Hooks laufen im Vorgang und dürfen ablehnen, Events folgen danach. Alle Hook-Punkte und was ein Hook nicht darf. Hook lehnt ab → 422Hook ändert MandantHook ändert StartrollenHook bei FROM_CALLER (nicht aufgerufen)Events |
| 3.15 Schutz der öffentlichen Endpunktecias/registrierung/oeffentliche-antworten | Warum die Selbstregistrierung immer dieselbe Antwort liefert, warum ungültige Links gleich aussehen und wie die Drosselung funktioniert. immer 202Link-Fehler 404, zweiter Klick 202Drosselung je AdresseDrosselung je Client429 ohne Retry-After |
| 3.16 Abgebrochene Registrierungen aufräumencias/registrierung/aufraeumen | Wie wartende Registrierungen nach Ablauf auf EXPIRED gesetzt, unbenutzte Konten gelöscht und alte Vorgänge entfernt werden. wartend abgelaufenersetzt durch neueren Versuchvon Hand verworfenalte Vorgänge löschen |
4. Benutzerverwaltung
Der fachliche Benutzerdatensatz in CIAS: Status, sperren, schließen, umziehen, Attribute pflegen, und warum die Reihenfolge der Schreibvorgänge über die Sicherheit entscheidet.
| 4.1 Der Benutzerdatensatzcias/benutzer/datensatz | Warum CIAS neben dem Keycloak-Konto einen eigenen Datensatz führt, was darin steht und was nie darin steht. Felder des Datensatzeswas nie darin stehtwie ein Datensatz entstehtAbfragen für Administratoren |
| 4.2 Der Lebenslauf eines Benutzerscias/benutzer/status | PENDING, ACTIVE, SUSPENDED, CLOSED: jeder Übergang und warum CLOSED endgültig ist. PENDINGACTIVESUSPENDEDCLOSED |
| 4.3 Die Schreibreihenfolgecias/benutzer/schreibreihenfolge | Beim Entziehen zuerst Keycloak, beim Gewähren zuerst CIAS. Warum genau so herum und was bei einem Ausfall dazwischen passiert. Zugang entziehenZugang gewährenAusfall zwischen den Schrittennur in CIAS |
| 4.4 Sperren, entsperren, schließencias/benutzer/sperren-schliessen | Die drei Statusoperationen im Ablauf, und dass Schließen das Konto deaktiviert, aber nicht löscht. sperrenentsperren (reaktivieren)schließenkein Löschen |
| 4.5 Bestehende Konten übernehmencias/benutzer/importieren | Wie CIAS Keycloak-Konten, die es noch nicht kennt, als Benutzer übernimmt. unbekanntes aktives Kontounbekanntes, nicht aktives Kontoschon bekanntübersprungen (mehrere Organisationen, Adresse vergeben) |
| 4.6 Umbenennen und Heimatmandant wechselncias/benutzer/umziehen | Was beim Umbenennen und beim Wechsel des Heimatmandanten passiert, und dass die Mitgliedschaft in Keycloak dabei nicht mitwandert. umbenennenHeimatmandant wechselnHeimatmandant entfernengeschlossene Person |
| 4.7 Attribute einer Person pflegencias/benutzer/attribute-pflegen | Die drei Speicherorte für Attribute (CIAS-intern, Keycloak-Profil, je Mandant) und wer was schreiben darf. CIAS-AttributeProfilattribute (landen im Token)Attribute je MandantDelegation je AttributObergrenze für Werte |
| 4.8 Passwort-Setz-Link erneut schickencias/benutzer/passwort-link | Wie ein Administrator einer Person einen neuen Link zum Setzen des Passworts schickt. Link schickenKonto nicht aktivZustellung nicht eingerichtetKeycloak-Erweiterung fehlt |
| 4.9 Selbstauskunft: eigener Mandant und Sprachecias/benutzer/selbstauskunft | Was eine angemeldete Person über sich selbst abfragen und ändern kann. eigener MandantSprache lesenSprache ändernnicht angeboten |
5. Mandanten
Der Mandant als Trennungsgrenze: statisch oder dynamisch, sein geschäftlicher Status, sein technischer Rollout, wie er bei jeder Anfrage aufgelöst und zugelassen wird und wie man zwischen Mandanten wechselt.
| 5.1 Statische und dynamische Mandantencias/mandanten/statisch-dynamisch | Ein statischer Mandant hängt an einem Benutzerattribut, ein dynamischer an einer Keycloak-Organisation. Wann welcher passt. STATICDYNAMIC |
| 5.2 Der Lebenslauf eines Mandantencias/mandanten/lebenszyklus | Zwei getrennte Zustände: die geschäftliche Stellung (PENDING bis CLOSED) und der technische Rollout (NOT_PROVISIONED bis PROVISIONED). Wann ein Mandant bedient wird. PENDINGACTIVESUSPENDEDCLOSEDNOT_PROVISIONEDIN_PROGRESSPROVISIONEDFAILEDGültigkeitsfenster |
| 5.3 Einen Mandanten anlegen und bereitstellencias/mandanten/anlegen | Absicht speichern, Datenbank anlegen und migrieren, Ergebnis speichern. Was in SINGLE, MULTI und bei einem eigenständigen CIAS passiert. MULTI: Datenbank anlegenSINGLE: nichtseigenständiges CIAS: nichtsFehlschlag → FAILED, wiederholbarhängender Rollout → nach 30 min FAILED |
| 5.4 Der Mandantenschlüsselcias/mandanten/schluessel | Warum der Schlüssel unveränderlich ist, welche Zeichen erlaubt sind und dass er zugleich der Datenbankname ist. Wie er bei einer Selbstregistrierung gebildet wird. aus Firmennameaus Mail-Domaineigene Bildungsregel |
| 5.5 Mandanten sperren, schließen, Gültigkeitcias/mandanten/sperren-schliessen | Was Sperren, Entsperren, Aktivieren, Schließen und ein Gültigkeitsfenster bewirken und warum es kein Löschen gibt. sperrenentsperrenaktivierenschließenGültigkeitsfenster setzenkein DELETE |
| 5.6 Den Mandanten einer Anfrage bestimmencias/mandanten/aufloesen | Die sechs Regeln, nach denen CIAS aus Token und Header den Mandanten bestimmt, mit den Ergebnissen RESOLVED, NONE, AMBIGUOUS und CONFLICT. keine Organisation, Attribut tenantkeine Organisation, kein Attribut → NONEAttribut widerspricht Mitgliedschaft → CONFLICTHeader wählt eigene Organisationgenau eine Organisationmehrere ohne Auswahl → AMBIGUOUS |
| 5.7 Den Mandanten zulassen (Mandanten-Tor)cias/mandanten/zulassen | Auflösen und Zulassen sind zwei Schritte. Wie das Tor fragt, 30 Sekunden merkt, bei Ausfall aus dem Gedächtnis antwortet und warum unbekannt und gesperrt gleich aussehen. CIAS erreichbarCIAS weg, Mandant bekanntCIAS weg, Mandant unbekanntgesperrter MandantSperre wirkt bis zu einer TTL später |
| 5.8 Zwischen Mandanten wechselncias/mandanten/wechseln | Auswahl unter eigenen Organisationen ohne besondere Rolle, privilegierter Wechsel mit Rolle, Benutzerwechsel, und dass nach jedem Wechsel erneut zugelassen wird. Auswahl eigener Organisationprivilegierter Wechselohne Rolle → still ignoriertZiel gesperrt → 403Benutzerwechsel |
| 5.9 In SINGLE zählt der Mandant im Token nichtcias/mandanten/single-ignoriert | In der Betriebsart SINGLE wird der Mandant im Token ignoriert: kein Tor, kein Wechsel. Warum das so ist und warum ein Schalter hier zwei Bedeutungen trägt. SINGLEMULTI |
| 5.10 Arbeiten für einen Mandanten ohne Anfragecias/mandanten/arbeit-ohne-anfrage | Wie Hintergrundarbeit (Timer, Jobs) für einen Mandanten läuft, durch dasselbe Tor, und welche drei Stellen einen Mandanten setzen dürfen. Mandant wird bedientMandant nicht bedientverschachteltohne Rollen |
6. Rollen und Rechte vergeben
Der Rollenkatalog, die Ebenen einer Rolle, wie Module ihre Rollen anmelden, wer Rollen vergeben darf, befristete Vergaben und wie eine Rolle ins Token kommt.
| 6.1 Der Rollenkatalogcias/rollen/katalog | Was CIAS zu jeder Rolle führt: Schlüssel und Client, Eigentümer-Modul, Scope, Delegation, Anzeigegruppe, Stilllegung. PLATFORMTENANTstillgelegt |
| 6.2 Realm-Rolle, Client-Rolle, Organisationsrollecias/rollen/ebenen | Die drei Ebenen, auf denen eine Rolle vergeben wird, wo sie im Token landet und wer sie liest. Realm-RolleClient-Rolle globalClient-Rolle in der Organisation |
| 6.3 Module melden ihre Rollen ancias/rollen/deklaration | Jedes Modul deklariert seine Rollen und Attribute selbst. Wie CIAS die Deklaration aufnimmt, eingebettet als Bean oder getrennt über /cias/fetch, und was bei einer abgelehnten Deklaration passiert.eingebettet (Bean)getrennt (GET /cias/fetch)REJECTED: nur dieses Modul fällt herausREFUSED: SchlüsselkollisionAttributwiderspruch stoppt allesModul deklariert Plattformrolle → abgelehnt |
| 6.4 Der Abgleich mit Keycloakcias/rollen/abgleich | Beim Start und auf Knopfdruck bringt CIAS Rollen, Profilattribute und Claim-Mapper in Keycloak auf den Stand. Warum zuerst Keycloak und dann der Katalog und warum nie gelöscht, sondern stillgelegt wird. beim Startauf Anforderungneue Rollezurückgezogene Rolle → stillgelegtPflichtattribut ohne Default → abgewiesen |
| 6.5 Wie eine Rolle aus dem Code ins Token kommtcias/rollen/rolle-ins-token | Der ganze Weg: Deklaration im Modul, Katalog, Anlage in Keycloak, Vergabe, Claim im Token. Mandantenrolle in einem dynamischen MandantenRolle über eine GruppeStartrolle einer Registrierung |
| 6.6 Eine Rolle vergebencias/rollen/vergeben | Wer darf vergeben? Plattform-Administrator immer, sonst nur mit Delegation, Obergrenze und im selben Mandanten. Der Ablauf mit allen Ablehnungen. Plattform-AdministratorMandanten-Administrator mit Delegationohne Delegation → 403über der Obergrenze → 403anderer Mandant → 403Mandant ohne Organisation → abgelehnt |
| 6.7 Befristete Rollencias/rollen/befristet | Vergaben mit Beginn und Ende: SCHEDULED, ACTIVE, EXPIRED, REVOKED, und wie ein Timer sie in Keycloak ein- und austrägt. SCHEDULEDACTIVEEXPIREDREVOKED |
| 6.8 Eine Rolle entziehencias/rollen/entziehen | Was beim Entziehen passiert, in welcher Reihenfolge, und wann es im Token ankommt. aktive Vergabegeplante Vergabeschon entzogenabgelaufen → 409Rolle in der Organisation |
| 6.9 Die Realm-Rollen der Plattformcias/rollen/plattformrollen | platform-admin, user, mail-template-admin, allowed-tenant-context-switch, allowed-user-context-switch, declaration-reader: wofür jede da ist und wer sie vergeben darf. platform-adminusermail-template-adminallowed-tenant-context-switchallowed-user-context-switchdeclaration-reader |
7. Gruppen
Gruppen als Rollenbündel mit Mitgliedern: anlegen, Mitglieder pflegen, Standardgruppe, Abgleich mit Keycloak und das Zusammenspiel mit dynamischen Mandanten.
| 7.1 Was eine Gruppe istcias/gruppen/was-ist-eine-gruppe | Ein Bündel aus Realm- und Client-Rollen mit Mitgliedern, geführt von CIAS, in Keycloak als markierte Kopie. Realm-Rollen in der GruppeClient-Rollen mehrerer Module in der GruppeGruppe ohne RollenStandardgruppe |
| 7.2 Gruppen und Mitglieder verwaltencias/gruppen/verwalten | Anlegen, ändern, löschen, Mitglieder aufnehmen und entfernen, bestehende Keycloak-Gruppen übernehmen. anlegenändernlöschenMitglied aufnehmenMitglied entfernenimportieren |
| 7.3 Die Standardgruppecias/gruppen/standardgruppe | Welche Gruppe jede neue Person automatisch bekommt und warum das nur für neue Konten wirkt. Registrierung abgeschlossenbestehendes Konto registriert sichKonto entsteht direkt in KeycloakGruppe wird StandardgruppeGruppe ist keine Standardgruppe mehrKeycloak nicht erreichbar |
| 7.4 Abgleich mit Keycloakcias/gruppen/abgleich | Wie der Sync-Zustand PENDING/SYNCHRONIZED entsteht und wann abgeglichen wird. beim Startauf Anforderung |
| 7.5 Gruppenrollen unter dynamischen Mandantencias/gruppen/grenzen | Warum global vergebene Client-Rollen, auch aus Gruppen, unter einem dynamischen Mandanten mit eigenen Rollen nicht gelten, und wie man Gruppen deshalb plant. Mandant ohne eigene RollenMandant mit eigenen RollenRealm-Rollen aus Gruppen |
8. Benutzerattribute
Angaben am Konto, die als Claim ins Token kommen und in CDMS Zeilen filtern: woher sie kommen, wie Module sie anmelden, wer sie schreiben darf und für welche Mandanten ein Wert gilt.
| 8.1 Zwei Herkünfte von Attributencias/attribute/herkunft | Plattformattribute (z. B. tenant) und Projektattribute aus dem Modell. Der Unterschied und warum er wichtig ist.PlattformattributProjektattribut |
| 8.2 Attribute anmeldencias/attribute/deklaration | Wie ein Modul ein Attribut deklariert, warum ein Pflichtattribut einen Standardwert braucht und wie der Attributkatalog entsteht. optionalPflicht mit StandardwertPflicht ohne Standardwert → abgewiesenVorliebe der Personpro Mandant |
| 8.3 Der Weg ins Tokencias/attribute/weg-ins-token | Profil in Keycloak, Claim-Mapper, Claim im Token, Attribut im RequestContext. ein Wertmehrere Wertekein WertWert pro Mandant |
| 8.4 Wer ein Attribut schreiben darfcias/attribute/wer-schreibt | Delegation je Attribut und Obergrenze für Werte: ein Administrator kann nur Werte vergeben, die er selbst hat. * heißt unbeschränkt.Plattform-AdministratordelegiertWert enthalten → okWert breiter → abgelehnt*nicht angemeldet oder zurückgezogen → abgelehntan die Person gebunden → abgelehnt |
| 8.5 Ein Wert pro Person oder pro Mandantcias/attribute/pro-mandant | Ein Attribut gilt entweder für die Person in allen Mandanten (USER) oder je Mandant getrennt (USER_IN_TENANT). Wie der passende Wert ins Token und in den Attributfilter kommt, wenn eine Person mehreren Mandanten angehört. USER: ein Wert für alle MandantenUSER_IN_TENANT: ein Wert je MandantPerson mit einem MandantenPerson mit mehreren MandantenCIAS nicht erreichbar |
| 8.6 Wie ein Attribut wieder verschwindetcias/attribute/verschwinden | Ein Attribut, das kein Modul mehr deklariert, wird stillgelegt, nicht gelöscht. Modul zieht das Attribut zurückein anderes Modul meldet es weiter anModul nicht erreichbarwieder angemeldet, vom selben Modulwieder angemeldet, von einem anderen Modul |
9. Benachrichtigungen
Welche Mails CIAS verschickt, wie die passende Vorlage gefunden wird und wer Vorlagen ändern darf.
| 9.1 Welche Mails es gibtcias/benachrichtigungen/mailarten | Jede Mail mit ihrem Anlass: Bestätigung, Beitrittseinladung, Einladung, bereits registriert, wartet auf Freigabe, abgelehnt, Willkommen, Passwort setzen, Freigabe für einen Benutzerwechsel. VERIFY_EMAILMEMBERSHIP_INVITATIONINVITATIONALREADY_REGISTEREDAPPROVAL_PENDINGREJECTEDWELCOMEPASSWORD_SETUPSWITCH_CONSENT_REQUESTEDSWITCH_CONSENT_USED |
| 9.2 Wie die passende Vorlage gefunden wirdcias/benachrichtigungen/vorlage-finden | Je Mail und Sprache eine Standardfassung, dazu die Fassung eines Mandanten: die Suche vom Mandanten zum Standard, Datenbank vor Auslieferung, und was bei einer kaputten Vorlage passiert. Mandant + SpracheMandant + SprachcodeStandard + SpracheStandard + SprachcodeStandard in der RückfallspracheAnwendung und Ablauf als Platzhalterkaputte Vorlage → übersprungen |
| 9.3 Vorlagen bearbeitencias/benachrichtigungen/vorlagen-bearbeiten | Wer welche Vorlage ändern darf: Editoren (Plattform-Administrator, mail-template-admin) alle, Mandanten-Administratoren nur eigene und nur freigegebene Arten. Standardfassung zurücksetzen statt löschen. EditorMandanten-Administratornicht freigegebene Art → abgelehntfremde Vorlage → abgelehntVorlage lässt sich nicht erzeugen → abgelehntStandardfassung zurücksetzenFassung eines Mandanten löschen |
| 9.4 Versand und Brandingcias/benachrichtigungen/versand | SMTP oder Log, Logo und Farben als Daten, Sprachen. SMTPLogBenachrichtigung ausgeschaltetBranding über den KontextBranding über eine eigene VorlageSprachen |
10. Audit in CIAS
Eine Protokollspur für die ganze Plattform: welche Ereignisse hineinkommen, was fehlt und wer sie lesen darf.
| 10.1 Eine Spur für allescias/audit/eine-spur | Ein einziger Zuhörer schreibt jedes fachliche Ereignis in eine Tabelle, die nur wächst. Wie ein Eintrag aussieht. Ereignis mit angemeldetem AufruferEreignis ohne Aufruferlanger Text wird gekürztSchreiben scheitertÄnderung wird zurückgerollt |
| 10.2 Welche Ereignisse protokolliert werdencias/audit/ereignisse | Welche Ereignisse in die Protokollspur kommen: Registrierung, Benutzer, Freigabe zum Benutzerwechsel, Mandant, Rollenvergabe. RegistrationEventUserEventSwitchConsentEventTenantEventAuthorizationEvent |
| 10.3 Das Audit lesencias/audit/lesen | Wer das Audit lesen darf und in welcher Form die Einträge vorliegen. Plattform-Administratoralle anderen → abgelehntSeite zu groß → abgelehnt |
| 10.4 CIAS-Audit und CDMS-Historiecias/audit/cias-und-cdms-audit | Zwei verschiedene Protokolle: CIAS protokolliert Ereignisse um Personen und Rechte, CDMS protokolliert Datenstände. Wann man wo nachsieht. Frage nach Rechten und Personen → CIAS-AuditFrage nach Daten → CDMS-HistorieFrage nach beidem |
11. Anbindung an den Identity Provider
Wie CIAS mit Keycloak spricht, ohne dass die Fachmodule Keycloak kennen: Ports und Adapter, der Keycloak-Adapter, der Speicher-Adapter für Tests und die Keycloak-Erweiterung.
| 11.1 Ports und Adaptercias/identity-provider/ports-adapter | Die Fachlogik spricht mit Schnittstellen („Ports“), ein Adapter übersetzt für Keycloak. Welche Ports es gibt und warum ein zweiter Provider ein zweites Artefakt ist. Keycloak-Adapter eingestelltSpeicher-Adapter eingestelltkein Provider eingestelltProvider nicht erreichbarProvider meldet KonfliktProvider kennt das Objekt nichtProvider lehnt abein zweiter Provider |
| 11.2 Der Keycloak-Adaptercias/identity-provider/keycloak-adapter | Was der Adapter in Keycloak anlegt und wie: Organisationen, Organisationsrollen als Gruppen, Profilattribute mit Rechten, Gesundheitsprüfung. Anmeldung als DienstkontoAnmeldung als AdministratorKonto anlegen und Zustand ändernOrganisation und MitgliedschaftRolle globalRolle in einer OrganisationRolle in einer Organisation entziehenProfilattribut: TatsacheProfilattribut: VorliebeClaim-Zuordnung anlegen oder korrigierenGesundheitsprüfung: erreichbarGesundheitsprüfung: nicht erreichbar |
| 11.3 Der Speicher-Adapter für Tests und Entwicklungcias/identity-provider/memory-adapter | Ein Identity Provider im Speicher, gegen dieselben Vertragstests geprüft, für Tests und lokale Entwicklung ohne Keycloak. VertragstestTest einer ganzen Anwendunglokale Entwicklung (Profil local)Rolle nicht angelegtPasswort-Link aus dem Speicherfremde Gruppe für einen TestNeustart |
| 11.4 Die Keycloak-Erweiterung für den Passwort-Linkcias/identity-provider/keycloak-erweiterung | Ein Jar, das in Keycloak läuft und den signierten Link zurückgibt, statt ihn selbst zu mailen. Was ohne die Erweiterung passiert. Erweiterung installiert: LinkErweiterung fehlt: kein LinkKonto unbekanntAnfrage abgelehntClient nicht freigegebenSpeicher-Adapter statt KeycloakKeycloak mit --optimized gestartet |
12. Sicherheitsprinzipien
Die Grundsätze hinter allen CIAS-Abläufen, an einer Stelle: im Zweifel ablehnen, ununterscheidbare Ablehnungen, keine Standardwerte für Rechte und das Verhalten bei Ausfällen.
| 12.1 Im Zweifel ablehnencias/sicherheit/fail-closed | Kein Standardmandant, keine Standard-Administratorrolle, Pflichtkonfiguration ohne Default. Warum eine Anwendung lieber nicht startet, als großzügig zu starten. kein Default-Mandantkeine Default-Rollenausdrücklich leer heißt niemandPflicht-BeansStart verweigertPflichtangabe in der Anfrage |
| 12.2 Ablehnungen, die nichts verratencias/sicherheit/ununterscheidbar | Unbekannt und gesperrt sehen gleich aus, öffentliche Endpunkte antworten immer gleich, Admin-Ablehnungen sind identisch. Warum man so nichts erfragen kann. Formular: neue und bekannte AdresseLink: unbekannt oder abgelaufenMandant: unbekannt, gesperrt oder nicht erreichbarVerwaltung: keine BerechtigungAbfragen für Dienste |
| 12.3 Wenn CIAS oder Keycloak ausfälltcias/sicherheit/ausfaelle | Was bei einem Ausfall passiert: Das Mandanten-Tor antwortet aus dem Gedächtnis, Registrierung und Verwaltung antworten mit 503, eine gescheiterte Bereitstellung bleibt wiederholbar. CIAS wegKeycloak weg bei AnfrageKeycloak weg bei RegistrierungKeycloak weg bei VerwaltungBereitstellung gescheitertNeustart während eines Ausfalls |
13. Oberflächen
Welche Oberflächen es für Anmeldung, Registrierung und Verwaltung gibt und welche Abläufe dort beginnen.
| 13.1 Die Login-Seiten (Keycloak-Theme)cias/oberflaechen/login-seiten | Welche Seiten das Login-Theme bereitstellt und welcher Ablauf zu welcher Seite führt. AnmeldenAnmelden in zwei SchrittenPasswort vergessenPasswort setzen oder ändernOTPE-Mail bestätigen (Keycloak)Seite abgelaufenFehler und HinweisAbmelden bestätigenRegistrieren (Keycloak) |
| 13.2 Die Verwaltungsoberflächecias/oberflaechen/verwaltung | Die Seiten für Benutzer, Mandanten, Rollen, Gruppen, Registrierungen und Mail-Vorlagen, und welche CIAS-Abläufe sie auslösen. BenutzerMandantenRollenGruppenRegistrierungenMail-Vorlagenohne Plattform-Administrator-RolleKonto ohne Mandant |
| 13.3 Registrieren und Bestätigencias/oberflaechen/registrierungsseiten | Die öffentlichen Seiten „Registrieren“ und „Bestätigen“ und wie sie ihr Formular aus der Feldbeschreibung des Servers bauen. Formular ladenAbsenden: angenommenAbsenden: zu schnell oder zu altAbsenden: abgelehnt, gedrosselt, abgeschaltetFalle ausgefülltschon angemeldetBestätigen: ohne FreigabeBestätigen: mit FreigabeBestätigen: Einstellung unbekanntLink unvollständig oder ungültig |
| 13.4 Das CIAS-Portalcias/oberflaechen/cias-portal | Das eigene Portal von CIAS: Anmeldung, Übersicht der Dienste mit ihrer CIAS-Anbindung, Statusanzeige. allein geöffnetaus dem Hub geöffnet (moduleId)Verbindung: bereitVerbindung: abgewiesenVerbindung: nicht bedientVerbindung: nicht erreichbarDienst startet so nichtListe leer oder nicht ladbar |
CDMS und CIAS im Zusammenspiel
Wie CDMS und CIAS zusammenarbeiten, als eine Einheit in einem Prozess oder als getrennte Services. Mit durchgespielten Abläufen von der Anmeldung bis zur Datenbank. Guter Einstieg für Neue.
1. Die Plattform auf einen Blick
Die Module, die Beteiligten einer Anfrage und die wichtigsten Begriffe in Bildern, bevor es in die Abläufe geht.
| 1.1 Die CodamAI-Modulezusammenspiel/ueberblick/module | CDMS, CIAS, CRMS, der Hub und die gemeinsamen Bausteine: wofür jedes Modul da ist, aus welchen Repositories es besteht und wie alles zusammenhängt. CDMS: Datenschicht und GeneratorCIAS: Identität und ZugangCRMS: BerichteHub: Oberfläche und zentrales Backendgemeinsame BausteineBibliothek, Dienst, Oberfläche, Werkzeug |
| 1.2 Die Beteiligten einer Anfragezusammenspiel/ueberblick/beteiligte | Benutzer, Browser, Frontend mit BFF, Keycloak, CIAS, CDMS, Datenbanken, Dateispeicher: wer mit wem spricht, eingebettet und getrennt. eingebettet: CDMS und CIAS in einem Prozessgetrennt: CIAS als eigener DienstFrontend: Hub-Oberfläche, CDMS-Portal, CIAS-Portal, CRMS-OberflächeAnwendung mit und ohne Dateispeicher |
| 1.3 Die wichtigsten Begriffe in Bildernzusammenspiel/ueberblick/begriffe | Token, Mandant, Benutzer, Rolle, Gruppe, Attribut, Modell, Hook, Revision: jeder Begriff mit einem Satz und einem Bild. TokenMandantBenutzerRolle (im Token und effektiv)GruppeAttribut (pro Person und pro Mandant)ModellHookRevision |
| 1.4 Wer entscheidet was?zusammenspiel/ueberblick/wer-entscheidet | Keycloak meldet an, CIAS gibt Bedeutung und schreibt Rechte, das Token trägt sie, CDMS setzt sie durch. Welche Frage welcher Teil beantwortet. Keycloak: Anmeldung und TokenCIAS: Bedeutung, Vergabe, Filterkette, Mandanten-TorToken: trägt die RechteCDMS: Durchsetzung auf den DatenHook: eigene Fachlogik des Projekts |
2. Eine Einheit oder getrennte Services
Die zwei Bauformen von CIAS neben CDMS: eingebettet in einem Prozess oder als eigener Service. Was jeweils läuft, wer wen aufruft, warum beide fachlich gleich sein müssen — und wie sich das zur Betriebsart der Datenhaltung, SINGLE oder MULTI, verhält.
| 2.1 CIAS eingebettet (eine Einheit)zusammenspiel/betriebsarten/eingebettet | CIAS läuft im selben Prozess wie CDMS oder das Hub-Backend. Welche Module eingebunden werden, wie CDMS CIAS aufruft und welche Datenbank CIAS nutzt. mit Starterohne Starter (hub-backend, generiertes Projekt)Mandantenprüfung per MethodenaufrufAttribut-Lookup per MethodenaufrufDeklaration als BeanSystem-Datenbank des Gastgebers |
| 2.2 CIAS als eigener Servicezusammenspiel/betriebsarten/getrennt | CIAS läuft als eigener Dienst. Was der CDMS-Dienst dann selbst mitbringt, welche Aufrufe über HTTP gehen und mit welchem Token. Mandantenprüfung per HTTPAttribut-Lookup per HTTPDeklaration per GET /cias/fetchDienst-Token statt Benutzer-Tokeneigene CIAS-DatenbankCIAS antwortet nicht |
| 2.3 Eingebettet und getrennt im Vergleichzusammenspiel/betriebsarten/vergleich | Alle Unterschiede zwischen „CIAS im selben Prozess“ und „CIAS als eigener Service“ in einer Übersicht: Artefakte, Aufrufe, Datenbank, Ausfallverhalten und die Verzögerung einer Sperre. eingebettet (eine Einheit)getrennt (zwei Services)CIAS erreichbar / nicht erreichbar |
| 2.4 Was läuft, bestimmt die Konfigurationzusammenspiel/betriebsarten/konfiguration | Jedes CIAS-Modul ist hinter einem Schalter ohne Standardwert. Warum keine CIAS-Klasse sich selbst aktiviert und was im Build entschieden wird (welcher Provider-Adapter). Modul anModul ausSchalter fehlt → Start scheitertGenerator: EMBEDDED / REMOTE / NONE |
| 2.5 SINGLE und MULTI über beide Modulezusammenspiel/betriebsarten/single-multi | Was die Betriebsart der Datenhaltung in CDMS und in CIAS bewirkt, und dass derselbe Schalter auch bestimmt, ob der Mandant im Token geprüft wird. SINGLEMULTISchalter fehltein Schalter für Datenhaltung und Mandantenprüfung |
| 2.6 Warum beide Arten fachlich gleich sein müssenzusammenspiel/betriebsarten/fachlich-gleich | Gleicher Code, gleiche Regeln, gleiche Ablehnungen. Was „fachlich gleich“ konkret heißt, wo der Unterschied trotzdem sichtbar wird und wo nicht. dieselbe Frage, zwei Wegegleich: Regeln, Antworten, Ablehnungenverschieden: Laufzeit, Ausfall, Startprüfungen |
3. Der Weg einer Anfrage, Ende zu Ende
Durchgespielte Abläufe über alle Beteiligten hinweg: von der Anmeldung bis zur Zeile in der Datenbank, der Weg des Tokens, die Mandantenprüfung in beiden Betriebsarten und was bei Ausfällen passiert.
| 3.1 Vom Login bis zu den Datenzusammenspiel/anfrageweg/login-bis-daten | Eine Person meldet sich an und öffnet eine Liste. Jeder Schritt über Browser, BFF, Keycloak, CIAS und CDMS bis zur Datenbank und zurück, in beiden Betriebsarten. eingebettet (ein Prozess)getrennt (zwei Dienste)erste Anfrage nach der Anmeldungspätere Anfrage aus der laufenden SitzungAccess-Token abgelaufenAbbruch an jeder Station |
| 3.2 Der Weg des Tokenszusammenspiel/anfrageweg/token-weg | Wo das Token entsteht, wo es liegt, wer es tauscht und wer es liest, bis es als RequestContext bei CDMS ankommt. Benutzer über ein PortalDownload mit Token in der AdresseDienst-Token für die LookupsLeser-Token für die Deklaration |
| 3.3 Die Mandantenprüfung in beiden Betriebsartenzusammenspiel/anfrageweg/mandantenpruefung | Wie das Mandanten-Tor eingebettet per Methodenaufruf und getrennt per HTTP fragt, mit Cache, Zeitlimit und Fehlerbehandlung. eingebettetgetrenntCache-TrefferZeitüberschreitung403 vom Lookup |
| 3.4 Wenn CIAS nicht erreichbar istzusammenspiel/anfrageweg/ausfall | Was CDMS im getrennten Betrieb tut, wenn CIAS ausfällt: bekannte Mandanten weiter bedienen, unbekannte ablehnen, mandantengebundene Attribute nicht lesbar. Mandant im CacheMandant unbekanntmandantengebundene AttributeAnfrage ohne MandantenNeustart während des Ausfalls |
| 3.5 Ein Schreibvorgang über alle Schichtenzusammenspiel/anfrageweg/schreibvorgang | Ein Formular wird gespeichert: vom Klick über BFF, Token-Prüfung, Rechte, Validierung, Hooks, Speichern, Audit und Commit bis zur Antwort. Anlegen (POST /create)Ändern (PUT und PATCH)Löschen (DELETE)Ablehnung in jeder StufeErfolg: Commit vor der AntwortFehler: Rollback der ganzen Anfrage |
4. Start, Bereitstellung, Abgleich
Was passiert, bevor die erste Anfrage kommt: Kaltstart, Anmeldung der Rollen und Attribute der Module bei CIAS, ein neuer Mandant von Anfang bis Ende und die Datenbankschemata.
| 4.1 Kaltstart einer Installationzusammenspiel/bereitstellung/kaltstart | Migrationen, Bootstrap (Plattformrollen, erster Mandant, erster Administrator), Aufnahme der Deklarationen, Abgleich von Rollen und Gruppen, in dieser Reihenfolge. Bootstrap anBootstrap auserster Administrator muss in Keycloak existiereneingebettetgetrennt |
| 4.2 Module melden Rollen und Attribute anzusammenspiel/bereitstellung/deklaration | Wie CDMS seine Rollen und Attribute an CIAS meldet, eingebettet als Bean, getrennt über /cias/fetch mit eigener Rolle, und was bei einer Ablehnung passiert.eingebettetgetrenntabgelehnt |
| 4.3 Ein neuer Mandant, Ende zu Endezusammenspiel/bereitstellung/neuer-mandant | Vom Anlegen in CIAS über die Organisation in Keycloak und die Datenbank bis zur ersten Anfrage in CDMS, die für diesen Mandanten durchs Tor geht. über die Verwaltungüber die Selbstregistrierungeingebettetgetrennt |
| 4.4 Datenbanken und Schematazusammenspiel/bereitstellung/schemata | Welche Datenbanken es gibt (System, je Mandant, CIAS), wer welches Schema migriert und in welcher Reihenfolge. System-DBMandanten-DBCIAS eingebettet (eigene Migrationshistorie)CIAS getrennt (eigene DB) |
5. Durchgespielte Szenarien
Typische Geschäftsfälle vom Anfang bis zum Ende, über CIAS und CDMS hinweg. Jedes Szenario verlinkt die Einzelseiten.
| 5.1 Ein neuer Kunde wird eingerichtetzusammenspiel/szenarien/neuer-kunde | Eine Firma registriert sich selbst, wird freigegeben, bekommt ihren Mandanten und ihre erste Administratorin, die sofort Daten anlegt. mit Freigabeohne FreigabeMULTI: eigene DatenbankSINGLE: keine eigene DatenbankAdresse schon bekanntSchlüssel schon vergebenBereitstellung scheitert |
| 5.2 Eine Kollegin wird eingeladenzusammenspiel/szenarien/mitarbeiter-einladen | Die Administratorin lädt eine Kollegin ein, die Kollegin bestätigt, setzt ihr Passwort und sieht die Daten ihres Mandanten, aber nur die, die ihre Rollen erlauben. Kollegin neuKollegin hat schon ein Konto bei einem anderen KundenLink abgelaufenzweimal geklicktAufrufer ohne Rolle oder ohne Mandant |
| 5.3 Eine Person in zwei Mandantenzusammenspiel/szenarien/zwei-mandanten | Eine Beraterin arbeitet für zwei Kunden. Wie sie zwischen den Mandanten wählt, welche Rollen jeweils gelten und welche Attributwerte für sie gelten. zwei Organisationen (Auswahl)statischer Mandant mit allowedTenants (privilegierter Wechsel)Rollen je MandantAttributwerte je Mandantkeine Auswahl geschickt |
| 5.4 Der Support schaut in einen Mandantenzusammenspiel/szenarien/support-wechsel | Ein Plattform-Mitarbeiter wechselt mit Rolle und Header in einen Kundenmandanten, um ein Problem nachzuvollziehen. Was er sieht und was nicht. nur MandantenwechselMandanten- und Benutzerwechsel, eigene RollenMandanten- und Benutzerwechsel, Bens RollenMandanten-Rolle fehlt → still ignoriertBenutzer-Rolle fehlt oder Ben nicht in nordbau → 403Ben hat nichts freigegeben → 403Freigabe beantragen und bestätigenZiel nicht erlaubtZiel gesperrtSupport ist selbst Mitglied (Auswahl) |
| 5.5 Eine Person verlässt die Firmazusammenspiel/szenarien/mitarbeiter-geht | Sperren, Rollen entziehen, Konto schließen: was sofort wirkt, was erst mit Ablauf des Tokens, und was mit ihren Daten und dem Audit passiert. Rollen entziehenKonto sperrenKonto schließenes muss sofort gehendie Person kommt zurück |
| 5.6 Ein Kunde kündigtzusammenspiel/szenarien/kunde-kuendigt | Der Mandant wird gesperrt und später geschlossen. Was mit Anmeldungen, laufenden Anfragen und der Datenbank passiert. Gültigkeitsfenster zum Vertragsendesofort sperrenschließendie Personen des Kundender Kunde kommt zurück |