Autorisierung über Zugriffskontrolle

Autorisierung ist der Prozess, bei dem Benutzern der Zugriff auf die verschiedenen Bereiche und Ressourcen der Webanwendung gewährt wird. Eine gängige Methode zur Autorisierung von Benutzern ist die Zugriffskontrolle, bei der der Administrator der Website festlegt, welche Berechtigungen Benutzern und anderen Entitäten gewährt werden müssen, um auf welche Ressourcen zugreifen zu dürfen.

Autorisierung darf nicht mit Authentifizierung verwechselt werden, die der Prozess ist, bei dem überprüft wird, ob der Benutzer tatsächlich der ist, der er vorgibt zu sein – in der Regel durch die Eingabe von Zugangsdaten. Sobald der Benutzer authentifiziert ist, muss der Autorisierungsprozess bei jeder Anfrage erneut durchgeführt werden, um sicherzustellen, dass der Benutzer Zugriff auf die angeforderte Ressource hat.

Wenn du die Anwendung über GraphQL aufrufst, müssen wir prüfen, ob der Benutzer Zugriff auf die angeforderten Elemente des Schemas hat. Soll die Autorisierungslogik in der GraphQL-Schicht kodiert werden?

Die Antwort lautet nein. Wie die Dokumentation auf graphql.org klarstellt, gehört die Autorisierungslogik in die Business-Logic-Schicht, von wo aus sie von GraphQL abgerufen wird. Auf diese Weise kann die Anwendung über eine einzige Quelle der Wahrheit für die Autorisierung verfügen (nämlich die von WordPress bereitgestellte):

Gato GraphQL respektiert dieses Prinzip und spiegelt den von WordPress bereitgestellten Autorisierungsmechanismus wider (und delegiert intern an diesen).

​

Zugriffskontrollrichtlinien

Unter den verschiedenen Zugriffskontrollrichtlinien, die wir für unsere Anwendung implementieren können, sind die zwei beliebtesten die rollenbasierte Zugriffskontrolle (RBAC) und die attributbasierte Zugriffskontrolle (ABAC).

WordPress und Gato GraphQL unterstützen beide.

Bei der rollenbasierten Zugriffskontrolle vergeben wir Berechtigungen auf Basis von Rollen und weisen diese Rollen dann den Benutzern zu. WordPress hat beispielsweise eine administrator-Rolle mit Zugriff auf alle Ressourcen sowie die Rollen editor, author, contributor und subscriber mit in unterschiedlichem Maße eingeschränkten Berechtigungen, wie z. B. das Erstellen und Veröffentlichen eines Blogbeitrags, nur das Erstellen oder nur das Lesen.

Bei der attributbasierten Zugriffskontrolle werden Berechtigungen auf Basis von Metadaten vergeben, die verschiedenen Entitäten zugewiesen werden können, darunter Benutzer, Ressourcen und Umgebungsbedingungen (wie die Uhrzeit oder die IP-Adresse des Besuchers). In WordPress wird beispielsweise die Fähigkeit edit_others_posts verwendet, um zu prüfen, ob ein Benutzer Beiträge anderer Benutzer bearbeiten darf.

Im Allgemeinen ist ABAC gegenüber RBAC vorzuziehen, da es uns ermöglicht, Berechtigungen mit feingranularer Kontrolle zu konfigurieren, und die Berechtigung in ihrem Zweck eindeutig ist.

In WordPress hat die Rolle editor beispielsweise die Fähigkeit edit_others_posts, aber wir möchten möglicherweise einer Person mit der Rolle author erlauben, den Beitrag eines anderen Autors zu bearbeiten, ohne ihr dabei den gesamten Berechtigungssatz zu gewähren, der einem Editor zugewiesen ist (wie z. B. auch das Löschen von Beiträgen anderer Autoren). Daher ist es angemessener, die Fähigkeit edit_others_posts zu vergeben und diese Bedingung zu prüfen, als die Rolle editor zu überprüfen.

​

Die Sichtbarkeit definieren

Wenn der Benutzer nicht über die Berechtigung verfügt, auf das angeforderte Feld im GraphQL-Schema zuzugreifen, welcher Fehler soll zurückgegeben werden?

Es gibt zwei Möglichkeiten, entsprechend der gewünschten Sichtbarkeit des Schemas: öffentlich oder privat.

Beim öffentlichen Schema ist das offengelegte GraphQL-Schema für alle Benutzer dasselbe, und jedes Feld beschreibt, welche Berechtigungen für den Zugriff erforderlich sind. Wenn ein nicht zugängliches Feld angefragt wird, erklärt die Fehlermeldung, warum dem Benutzer der Zugriff nicht gewährt wird.

Beim privaten Schema ist das GraphQL-Schema für jeden Benutzer individuell angepasst, und es werden nur die Felder angezeigt, auf die der Benutzer zugreifen kann. Wenn ein nicht zugängliches Feld angefragt wird, gibt die Fehlermeldung an, dass das Feld nicht existiert.

​

Zugriffskontrolle über die Benutzeroberfläche

In Gato GraphQL werden die Zugriffskontrollregeln zur Laufzeit in das Schema injiziert, als benutzerdefinierte Konfiguration über access control lists. Auf diese Weise spiegelt die GraphQL-Schicht Änderungen an der Zugriffskontrollrichtlinie sofort wider, ohne dass Code aktualisiert oder das Schema neu kompiliert werden muss:

Der Site-Administrator konfiguriert die ACL und wählt dabei:

• Die zu validierenden Felder
• Eine zu validierende Regel, aus:
  • muss der Benutzer eingeloggt sein?
  • muss der Benutzer ausgeloggt sein?
  • muss der Benutzer eine bestimmte Rolle haben?
  • muss der Benutzer eine bestimmte Fähigkeit haben?
• Die regelspezifische Konfiguration:
  • welche Rollen?
  • welche Fähigkeiten?
• Die Sichtbarkeit:
  • Standard (d. h. dieselbe, die dem Schema zugewiesen ist)?
  • öffentlich?
  • privat?