Anmeldestufe je Modell und Operation

Worum es geht

Eine Rolle sagt, wer eine Operation ausführen darf. Manchmal reicht das nicht. Gesundheitsdaten etwa soll nur lesen, wer sich mit einem zweiten Faktor angemeldet hat, also zusätzlich zum Passwort mit einem Code aus einer App oder einem Sicherheitsschlüssel. Und ändern soll sie nur, wer sich gerade eben angemeldet hat, nicht vor drei Stunden.

Dafür trägt ein Modell je Operation eine Anmeldeanforderung. Sie besteht aus zwei Teilen:

• der Anmeldestufe: wie stark du dich mindestens angemeldet haben musst,
• optional dem Höchstalter der Anmeldung: wie viele Sekunden deine Anmeldung höchstens zurückliegen darf.

Erfüllst du die Anforderung nicht, antwortet CDMS mit 401 und dem Schlüssel cias.authentication.step-up-required|…. Dein Token ist dabei gültig. Es fehlt nur eine stärkere oder frischere Anmeldung. Das Nachholen dieser Anmeldung heißt Step-up.

Es gibt drei Anmeldestufen, jede schließt die darunter ein:

Woher CIAS die Stufe deiner Anmeldung kennt, steht unter Anmeldestufe und Step-up.

So gibst du sie an

In der Modelldatei (models.yaml) steht die Anforderung als eigene Liste authentication neben den Rollen. Jeder Eintrag nennt eine Operation:

- name: "Record"
  "@type": "DataModel"
  roles:
    - type: "READ"
  authentication:
    - type: "READ"        # Lesen nur mit zweitem Faktor, egal wie lange her
      level: "MFA"
    - type: "UPDATE"      # Ändern nur mit zweitem Faktor aus den letzten 5 Minuten
      level: "MFA"
      maxAge: 300

Eine Operation ohne Eintrag verlangt nichts über ihre Rolle hinaus. Die Anforderung ist unabhängig von den Rollen: Eine Operation kann eine Anmeldestufe verlangen, ohne eine eigene Aktionsrolle zu haben. Feiner als je Operation geht es nicht, einzelne Felder tragen keine Anforderung.

Welche Operation was verlangt

Du gibst nur die vier Operationen an. Jeder Endpunkt gehört zu einer davon:

Zwei Punkte darin sind wichtig:

• Die Antwort eines Schreibvorgangs ist ein Lesen. Anlegen und Ändern geben den gespeicherten Datensatz zurück. Verlangt das Modell für READ einen zweiten Faktor, verlangt es ihn also auch dort. Fehlt er, rollt CDMS den Schreibvorgang zurück und antwortet 401. Es bleibt nichts gespeichert, deshalb darf der Client die Anfrage nach der neuen Anmeldung einfach wiederholen.
• Eine Suche wird ganz abgelehnt. Verlangt READ mehr, als deine Anmeldung bietet, antwortet POST /query mit 401. CDMS filtert keine Zeilen heraus und liefert keine leere Liste. Sonst sähe es so aus, als gäbe es keine Daten.

Auch eine Beziehung zählt. Nennt deine response ein Feld, das in ein Modell mit Anforderung führt, gilt dessen Anforderung für READ. Das gilt auch, wenn du das Modell über eine Feldrolle erreichst.

Erst die Berechtigung, dann die Anmeldung

Beim Ändern und Löschen kommt wie immer zuerst die Zeile, dann die Rolle, dann die Anmeldung. Siehe Die drei Ebenen im Überblick.

Wer die Berechtigung nicht hat, wird nach der Anmeldung gar nicht gefragt. Er bekommt die Antwort wie bisher. Wer sie hat und die Anmeldung nicht erfüllt, bekommt immer 401, auch ohne Strict Mode.

Wann deine Anmeldung die Anforderung erfüllt:

• Deine Stufe ist mindestens die verlangte. phishing-resistant erfüllt auch mfa.
• Ist ein Höchstalter gesetzt, liegt deine Anmeldung höchstens so viele Sekunden zurück. Ein Token ohne Anmeldezeit erfüllt nie ein Höchstalter.
• Ein Token ohne oder mit unbekannter Stufe zählt als basic.

Die Antwort 401

PUT /api/rest/health/record/update/5a2b…
{ "data": { "id": "5a2b…", "label": "neu" }, "response": ["id", "label"] }

WWW-Authenticate: Bearer error="insufficient_user_authentication",
  error_description="A stronger or more recent sign-in is required",
  acr_values="mfa", max_age=300

{
  "messageKey": "cias.authentication.step-up-required|mfa|300",
  "code": "401",
  "layer": "api"
}

Der messageKey nennt die Stufe und, falls gesetzt, das Höchstalter in Sekunden. Ohne Höchstalter endet er nach der Stufe: cias.authentication.step-up-required|mfa, und im Header fehlt max_age. Der Header folgt dem Standard RFC 9470. Er sagt einem Client, womit er sich neu anmelden muss: acr_values ist die Stufe, max_age das Höchstalter.

Wie Frontend und Anmeldung darauf reagieren, also erneut anmelden und die Anfrage einmal wiederholen, steht unter Eine stärkere Anmeldung nachholen (Step-up).

Abstrakte Modelle und Untertypen

Ein Untertyp eines abstrakten Modells erbt die Anforderungen seiner Eltern. Sonst wäre sein eigener Endpunkt ein Weg an der Regel der Eltern vorbei.

Gibt der Untertyp für dieselbe Operation selbst eine an, gilt die strengere: die höhere Stufe und das kürzere Höchstalter. Ein Untertyp kann also verschärfen, aber nie lockern.

Öffentliche Operationen

Eine Operation mit publicAccess: true braucht keine Rolle. Sie kann keine Anmeldung verlangen, denn dort fragt niemand nach einer Person. Verlangt ein Modell für eine Operation eine Anmeldestufe und bietet dieselbe Operation öffentlich an, bricht der Generator den Build ab. Dabei zählen Herunterladen und Historie als READ, ein Rollback als UPDATE. Siehe Modellrollen.

Wer nicht gefragt wird

Im Hub einstellen

Im Hub steht in der Ansicht eines Modells direkt unter den Berechtigungen der Block Anmeldung, etwa „Anmeldung (1 von 4 Aktionen mit Anforderung)“. Er zeigt für jede Aktion die Stufe und das Höchstalter.

Mit Bearbeiten öffnest du den Dialog Anmeldung konfigurieren. Für jede Aktion (Anlegen, Lesen, Aktualisieren, Löschen) setzt du einen Haken „Anmeldung für … verlangen“. Dann wählst du die Mindeststufe (Angemeldet, Zweiter Faktor, Passkey / phishing-resistent) und, wenn du willst, das Höchstalter (Sekunden). Leer heißt: beliebig alt. Beim Build landet das als Liste authentication in der Modelldatei.

Ändert ein KI-Client das Modell über den MCP-Server, kann sein Blueprint ebenfalls authentication angeben. An einem vorhandenen Modell ergänzt der Hub dann nur Operationen, die noch keine Anforderung haben. Eine gespeicherte Anforderung, die abweicht, bleibt stehen, und der Hub meldet die Abweichung als Warnung. Der MCP-Server lockert also nie einen Schutz. Ändern kannst du sie nur im Hub selbst. Siehe Schemaänderung über den MCP-Server.

CIAS kennt die Stufen

Beim Build sammelt der Generator alle Stufen, die irgendein Modell verlangt. CDMS meldet sie CIAS zusammen mit Rollen und Attributen, im getrennten Betrieb über GET /cias/fetch im Feld authenticationLevels. CIAS prüft im Abgleich, ob die Anmeldung diese Stufen überhaupt erreichen kann, und meldet eine Stufe, bei der das nicht geht. Siehe Module melden Rollen und Attribute an.

Fallen

Wie es weitergeht

• Was Anmeldestufen sind und woher CIAS sie kennt: Anmeldestufe und Step-up
• Der ganze Weg vom 401 bis zur wiederholten Anfrage: Step-up
• Welche Rolle eine Operation verlangt: Modellrollen
• Wie ein Client auf 401 reagiert: 401, 403 oder 404?