Zusammenfassung

  • RFC 9865 definiert einen für den Client opaken SCIM-Cursor, der dieselbe Abfrage am selben Endpoint auf die nächste Ergebnisseite fortsetzt.
  • Der Besitz des Cursors erweitert keine Berechtigung; für jede Seite ist die Autorisierung der gegenwärtigen Akteursidentität weiter anzuwenden.

Ein Cursor ist betriebswirtschaftlich verführerisch, weil er eine lange Liste wie einen fortlaufenden Arbeitsvorrat aussehen lässt. Ein Job liest die erste Seite, legt den Zustand ab und soll später „einfach weitermachen“. Doch gerade zwischen zwei Seiten verändern sich Gruppen, Rollen, Sperren und lokale Regeln. Wer aus der erfolgreichen ersten Seite eine reservierte Zugriffsposition ableitet, verlegt die Kontrollentscheidung in einen technischen Zeiger. Das ist nicht die Rolle, die RFC 9865 dem Cursor gibt.

Die Norm bindet die Fortsetzung an die ursprüngliche Abfrage. Beim ersten cursorpaginierten Aufruf ist cursor leer oder fehlt. Für die nächste Seite müssen Service-Provider-Endpoint sowie alle ursprünglichen Parameter und Werte gleich bleiben; nur der Cursor wird durch einen zuvor erhaltenen Wert ersetzt. Der Wert ist für den Client opaque. Jede paginierte Antwort außer der letzten enthält nextCursor; previousCursor ist optional und auf der ersten Seite verboten. Damit ist überprüfbar, ob eine Anfrage in derselben Abfragesequenz bleibt. Nicht überprüfbar wird dadurch, ob der Ergebnisbestand vollständig, unverändert oder weiterhin für den Akteur bestimmt ist.

Auch die Zahlen auf dem Bildschirm sind begrenzt aussagekräftig. count ist eine gewünschte Obergrenze, die der Provider nicht überschreiten darf, aber unterschreiten darf. Bei count=0 kommen keine Ressourcen zurück, allenfalls totalResults; kann der Provider den Wert nicht schätzen, darf er ihn weglassen. Eine ausgespielte Gesamtzahl ist daher keine Inventarbescheinigung. Ein Provider darf Cursor als einzige Paginierungsform verlangen. Unterstützt er auch Indizes, wählt er ein Standardverfahren und kann dies in der Service Provider Configuration veröffentlichen.

Der eigentliche Schutzsatz liegt in den Security Considerations. Ergebnisse müssen strikt auf Daten beschränkt bleiben, die die aktuelle Identität des Akteurs lesen darf — auch wenn der Cursor aus einer von einem anderen Akteur erzeugten Ergebnismenge stammt. Die Autorisierungsprüfung muss während der gesamten Navigation fortlaufen. Cursor-Besitz darf unter keinen Umständen als zusätzlicher Zugriffsvorteil gelten. Ein richtig gebauter Dienst prüft damit nicht, ob der Cursor einmal legitim ausgestellt wurde, sondern ob der angefragte Inhalt jetzt unter der geltenden Regel sichtbar ist.

Nach einer Berechtigungsänderung soll der Anbieter zugehörige Cursor, soweit möglich, sofort ungültig machen. Behält er sie, müssen Metadaten wie Zähler den neuen Berechtigungsumfang wiedergeben. Cursor sollen sich nicht auslesen oder fälschen lassen; Fehlermeldungen dürfen nicht verraten, ob eine Seite existiert, aber verboten ist. Daraus folgt auch die Gegenrichtung: Ein expiredCursor beweist keine konkrete Entziehung, und eine erfolgreiche Folgeseite beweist keine unveränderte Berechtigung. Beides sind eng abgegrenzte Betriebsereignisse.

Verfügbarkeit setzt dem Zustand weitere Grenzen. Bewahrt ein Provider pro Cursor umfangreiche Daten, können viele Erstabfragen seine Ressourcen erschöpfen. RFC 9865 empfiehlt Authentisierung großer Mengen, Rate Limits, administrative Obergrenzen für Cursor oder Seitengrößen und eine ressourcenschonende Invalidierung. Nicht veröffentlichte Timeout- oder Größenwerte dürfen nicht als fehlende Begrenzung verstanden werden. Das nicht sichtbare lokale Limit bleibt eine lokale Tatsache.

Heng Lus Trennung von gemeinsamer Regel und lokaler Entscheidung hält die Aussage belastbar. Die RFC schafft ein deterministisches Koordinationsmittel für den nächsten Abruf. Aktuelle Identität, Policy, Implementierung und die Folgeentscheidung aus den Daten liegen außerhalb dieses Mittels. Der Cursor macht Fortsetzung möglich; das Recht muss der Dienst erneut feststellen.

Sources