Rollenbasierte Zugangskontrolle

Rollenbasierte Zugangskontrolle (RBAC) ist eine Methode, um Benutzern basierend auf ihren Rollen Berechtigungen zuzuweisen. Erwäge die Verwendung von RBAC in den folgenden Szenarien:

• Du hast mehrere Benutzer mit unterschiedlichen Zugriffsanforderungen: RBAC ist ideal, wenn Benutzer unterschiedliche Berechtigungen basierend auf Rollen wie Admin, Editor oder Betrachter benötigen.
• Du musst die Berechtigungsverwaltung vereinfachen: Es ist effizient für die Verwaltung großer Benutzergruppen, indem Rollen zugewiesen werden, anstatt Berechtigungen individuell festzulegen.
• Deine App bedient verschiedene Abteilungen oder Teams: Es ist nützlich in Szenarien, in denen verschiedene Gruppen unterschiedliche Zugriffsebenen auf Ressourcen benötigen.

Verstehe, wie rollenbasierte Zugangskontrolle funktioniert

Berechtigungen (Berechtigungen)

Berechtigung bezieht sich auf die Autorisierung zum Zugriff auf eine [API-Ressource]. In der realen Welt können Entitäten wie Bestellungen, Produkte und Dokumente als Ressourcen bezeichnet werden, und verschiedene Aktionen können zugewiesen werden.

Beispiele für Berechtigungen, einschließlich der Fähigkeit, eine Bestellung zu bearbeiten, ein Dokument zu lesen und ein Produkt zu löschen, sind wie folgt:

• write:orders
• read:documents
• delete:products

Die obige Abbildung zeigt, dass die Berechtigung read:item in der Ressource https://api-1.store.io sich von der Berechtigung read:item in der Ressource https://api-2.store.io unterscheidet.

Wenn keine API-Ressource angegeben wird, wird die Berechtigung als "für OIDC" behandelt. Normalerweise ist dies nicht das, was du in RBAC möchtest.

Rollen

Rollen sind eine Gruppierung von Berechtigungen, die Benutzern zugewiesen werden können. Sie bieten auch eine Möglichkeit, Berechtigungen, die für verschiedene APIs definiert sind, zusammenzufassen, was das Hinzufügen, Entfernen oder Anpassen von Berechtigungen effizienter macht, als sie Benutzern individuell zuzuweisen.

Hier ist ein Beispiel für eine order_admin-Rolle mit mehreren Berechtigungen für zwei Ressourcen:

Es ist in Ordnung, wenn sich Berechtigungen zwischen Rollen überschneiden.

Beispiel: Ein Online-Buchladen

Angenommen, du hast einen Online-Buchladen zu verwalten. Hier vereinfachen wir das Zugriffssteuerungsmodell stark zu Demonstrationszwecken.

Das Modell ist in zwei Haupt-API-Ressourcen unterteilt: Bestellungen und Produkte. Sie haben unterschiedliche Ressourcenindikatoren wie unten:

• Bestellungen: https://api.store.io/orders
• Produkte: https://api.store.io/products

Für jede Ressource möchtest du die Berechtigungen in Lesen, Schreiben und Löschen unterteilen. Also definierst du insgesamt sechs Berechtigungen:

• https://api.store.io/orders
  • Berechtigung read:order
  • Berechtigung write:order
  • Berechtigung delete:order
• https://api.store.io/products
  • Berechtigung read:product
  • Berechtigung write:product
  • Berechtigung delete:product

Hier ist die Darstellung dieses Modells:

Du möchtest zwei Arten von Admins haben, Bestellungs-Admin und Produkt-Admin:

• Bestellungs-Admin kann Bestellungen verwalten und Produkte sehen (da Bestellungen aus Produkten bestehen), aber keine Produkte verwalten.
• Produkt-Admin kann Produkte verwalten und sollte keine Kenntnis von Bestellungen haben.

Also erstellst du zwei Rollen, order_admin und product_admin, mit den Berechtigungen:

• order_admin
  • https://api.store.io/orders
    • read:order, write:order, delete:order
  • https://api.store.io/products
    • read:product
• product_admin
  • https://api.store.io/products
    • read:product, write:product, delete:product

Hier ist die Darstellung dieser beiden Rollen:

Es ist in Ordnung, sowohl order_admin als auch product_admin einem Benutzer zuzuweisen, dann haben sie alle sechs Berechtigungen, die du gerade definiert hast.

Beachte, dass der Bestellungs-Admin die Berechtigung read:product mit dem Produkt-Admin teilt, und die endgültigen Berechtigungen, die ein Benutzer hat, die Vereinigung aller Berechtigungen aus den Rollen sind, die ihm zugewiesen wurden.