Zusammenfassung

  • RFC 3744 behandelte einen Principal als Webressource mit möglicherweise mehreren URLs, verlangte für einen Eintrag zur Zugriffskontrolle aber die kanonische Referenz DAV:principal-URL.
  • Namenssuche und angekündigte Principal-Sammlungen halfen bei der Kandidatensuche; sie versprachen weder ein vollständiges Verzeichnis noch Authentifizierung oder Zugriff.

Der angezeigte Name war nicht der Bezugspunkt der Regel

WebDAV machte es möglich, entfernte Dokumente und Sammlungen über HTTP zu bearbeiten. Seine Erweiterung zur Zugriffskontrolle musste festlegen, wer welche Operation an einer Ressource ausführen durfte. Eine Namensliste schien für die Oberfläche naheliegend. Das Protokoll brauchte jedoch etwas anderes: Ein Name hilft Menschen beim Erkennen, ein Access Control Entry (ACE) muss einen vom Server auswertbaren Principal referenzieren.

Die im Mai 2004 veröffentlichte RFC 3744 stellte einen Principal – einen Menschen oder einen Rechnerakteur – als Netzwerkressource dar. Derselbe Principal konnte mehrere URLs besitzen, etwa eine technische und eine lesbare. Aus der Schreibweise allein konnte ein Client nicht ableiten, dass beide denselben Akteur bezeichneten. DAV:displayname lieferte eine menschenlesbare Bezeichnung, aber keinen Identitätsschlüssel.

Die Spezifikation führte deshalb eine Kanonisierung ein. Die geschützte Eigenschaft DAV:principal-URL lieferte unabhängig davon, über welche URL sie abgefragt wurde, stets dieselbe festgelegte URL. Beim Anlegen eines ACE musste der Client eine Principal-URL verwenden. Auch die Mitgliederliste einer Gruppe verwies auf jedes Mitglied über dessen Principal-URL. So wurde der Regelbezug stabil, ohne alle sichtbaren Aliase abschaffen zu müssen.

Das war wichtig, weil eine ACL an einer Ressource hängt und ACEs Principals mit Privilegien verbinden. Wenn eine ACE einen Alias nannte, konnte ein anderer Client nicht allgemein feststellen, ob eine weitere URL gleichwertig war. RFC 3744 verlegte diese Beziehung in eine geschützte, vom Server gepflegte Eigenschaft, statt jeden Client raten zu lassen.

Suche bedeutete keine vollständige Aufzählung

Bei Hunderten oder Tausenden Principals brauchten Menschen eine Auswahlhilfe. RFC 3744 definierte DAV:principal-property-search für Teilzeichenfolgensuchen über ausgewählte Eigenschaften sowie einen getrennten Report, der die durchsuchbaren Eigenschaften bekannt machte. Das war flexibler als eine feste Sammlungshierarchie, versprach aber keinen Zugriff auf jedes Identitätsmerkmal.

Der Server durfte die durchsuchbaren Eigenschaften begrenzen. DAV:principal-collection-set konnte einige Principal-Sammlungen oder gar keine nennen. Es garantierte deshalb kein vollständiges Verzeichnis. Ein Treffer war ein Kandidat, den die unterstützte Suchschnittstelle dieses Servers gefunden hatte. Kein Treffer bewies nicht, dass der Principal fehlte; zwei Treffer bewiesen ebenso wenig, dass sie dieselbe Person bezeichneten.

Der Ablauf beantwortete zwei Fragen: „Welche Ressource will der Bediener auswählen?“ und „Welche kanonische URL gehört in das ACE?“ Keine beantwortete „Wer sendet diese Anfrage tatsächlich?“. RFC 3744 überließ Authentifizierung den HTTP-Mechanismen. Bei der ACE-Auswertung musste der Server den Anfragenden weiterhin validieren und die ACL anwenden. Anzeigename, Suchtreffer, kanonischer Bezug, Authentifizierungsnachweis und effektives Privileg sind unterschiedliche Datensätze.

Eine Schnittstelle, kein vollständiges Identitätssystem

RFC 3744 legte weder fest, wie Principal-Ressourcen und Gruppen erstellt und gepflegt werden, noch wie eine anfängliche ACL entsteht. Die Spezifikation bot interoperable Referenzen und Suchberichte, die sich mit verschiedenen Benutzerverwaltungen verbinden ließen. Vollständigkeit des Verzeichnisses und Lebenszyklus-Governance blieben außerhalb ihres Umfangs.

Der historische Beitrag war ein begrenzter, klarer Vertrag: Aliase können bestehen; ACEs benötigen eine kanonische Principal-URL; Auffindbarkeit hängt von den Serverfunktionen ab; Authentifizierung und Autorisierung bleiben getrennte Prüfungen. Der RFC belegt dieses Design, nicht die Verbreitung in einem bestimmten Produkt, die Vollständigkeit eines realen Verzeichnisses oder den Ausgang eines Vorfalls.

Quellen