Zusammenfassung

  • Der Entwurf definiert GroupMembership als eigene Ressource pro Verbindung von Gruppe und Mitglied. Filter und Seitenzugriff sollen die Kontrolle auch bei großen Gruppen erlauben.
  • Ein optionales membersEmbedded kennzeichnet, ob die in einer Gruppenantwort enthaltene Liste vollständig ist. Der Wert false gibt keine Vollständigkeitszusage; eine bewusst ausgeschlossene Liste lässt sich auch bei true nicht als leere Gruppe lesen.

Ein Schreibrecht ohne Leserecht taugt schlecht zur Revision

Nach RFC 7643 steckt die Mitgliedschaft als mehrwertiges Attribut members in der Gruppe. Der Entwurfsautor beschreibt die Kehrseite: Bei sehr großen Gruppen wird die Antwort schwer, manche Implementierungen liefern das Attribut nicht, manche Clients fordern es ausdrücklich nicht an. Diese Clients können Änderungen senden, aber den tatsächlichen Bestand beim Dienstanbieter nicht mehr mit dem gewünschten Bestand abgleichen. Der Entwurf liefert keine unabhängige Erhebung zur Häufigkeit. Der Mechanismus lässt sich trotzdem klar untersuchen.

/GroupMemberships würde eine Beziehung mit einer vom Anbieter vergebenen, undurchsichtigen ID versehen. Filter könnten alle Mitglieder einer Gruppe, alle Gruppen eines Mitglieds oder genau ein Paar liefern. Eine zweite Anlage desselben Paars müsste mit einem Konflikt enden. Wer einen Zugang entziehen will, bekäme so eine adressierbare Beziehung statt einer undurchsichtigen Änderung an einer riesigen Liste.

Das kleine Feld membersEmbedded verhindert einen großen Fehlschluss. true wäre die Garantie, dass members alle aktuellen Mitglieder enthält, sofern die Anfrage die Rückgabe dieses Attributs erlaubt. Hat der Client es selbst ausgeschlossen, beweist sein Fehlen keine leere Gruppe. false kann eine vollständige, teilweise oder fehlende Liste begleiten; der Anbieter übernimmt dafür keine Vollständigkeitsgarantie. Ohne Feld bleibt die Auslegung des bisherigen SCIM-Modells maßgeblich. Wer Gewissheit braucht, fragt die neue Ressource mit einem Gruppenfilter ab.

Der Entwurf verlangt dort alle Mitgliedschaften, die der anfragende Client sehen darf. Eine vollständig gelesene Berechtigungssicht ist folglich nicht automatisch ein unternehmensweites Gesamtverzeichnis. Gruppen- und Mitglieds-ID müssen sich mit Gleichheitsfiltern abfragen lassen. Mindestens eine Form der Seitennavigation ist Pflicht, Cursor werden empfohlen: Bei laufenden Änderungen können Indexpositionen verrutschen. Selbst die zugesagte stabile Reihenfolge setzt voraus, dass sich der Bestand während der Abfrage nicht ändert.

Die eigentliche Betreiberpflicht entsteht, wenn beide Schreibwege offen bleiben. Eine Löschung über Group.members und eine über /GroupMemberships müssen denselben Zustand erzeugen; beim Löschen einer Gruppe oder Person müssen die zugehörigen Verbindungen verschwinden. Sonst zeigen zwei Schnittstellen zwei verschiedene Zugangsrechte. Der IETF-Eintrag weist den Text als individuellen Entwurf aus. Eine Arbeitsgruppenübernahme oder nachprüfbare Implementierung fehlt bislang und wäre der nächste belastbare Schritt.

Quellen: Originalentwurf; IETF-Status; RFC 7643; RFC 7644; RFC 9865.