Beherrschen von RBAC in Logto: Ein umfassendes Real-World-Beispiel
Dieser Artikel bietet einen umfassenden Leitfaden zum Beherrschen der rollenbasierten Zugriffskontrolle (RBAC) in Logto, unter Verwendung eines realen Beispiels eines Online-Buchladens, um wichtige Benutzerrollen, Bereiche und die Integration der RBAC-Funktionen von Logto in Frontend- und Backend-Anwendungen für verbesserte Sicherheit und Zugriffskontrolle zu erkunden.
SijieDeveloper
Verschwenden Sie keine Wochen mit Benutzerauthentifizierung
Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.
Zugriffskontrolle und Sicherheit sind wesentliche Aspekte moderner Anwendungen, die sicherstellen, dass Benutzer geeigneten Zugang zu Ressourcen haben. Logto's rollenbasierte Zugriffskontrolle (RBAC) bietet Entwicklern eine effiziente Möglichkeit, die Zugriffskontrolle und Sicherheit in ihren Anwendungen zu verwalten. In diesem Artikel werden wir die leistungsfähigen Funktionen der RBAC-Implementierung von Logto anhand eines realen Beispiels erkunden, um Ihnen zu helfen, diese Konzepte in Ihren Projekten zu verstehen und anzuwenden.
Durch die Untersuchung sowohl von Frontend- als auch von Backend-Codeausschnitten gewinnen Sie einen umfassenden Einblick, wie Sie RBAC von Logto in Ihren Anwendungsstapel integrieren können. Am Ende dieses Artikels werden Sie gut ausgerüstet sein, um die RBAC-Funktionen von Logto zu
utzen und die Sicherheit und Zugriffskontrolle Ihres Projekts zu verbessern.
Vorstellung von BookHarber: Ein Online-Buchhandel Anwendungsfall#
Um die RBAC-Funktionen von Logto effektiv zu demonstrieren, werden wir ein reales Beispiel verwenden: BookHarber, eine Online-Buchhandlung. BookHarber bietet eine breite Palette von Funktionen für Kunden und Mitarbeiter, um ein
ahtloses und sicheres Einkaufserlebnis zu gewährleisten.
Die wichtigsten Funktionen von BookHarber sind:
Durchsuchen und Kaufen von Büchern: Benutzer können leicht
ach Büchern suchen und diese aus einer diversen Sammlung, die verschiedene Genres und Autoren umfasst, kaufen.
Bestellverwaltung und Logistikverfolgung: Registrierte Kunden können ihre Bestellungen verwalten, den Versand verfolgen und Aktualisierungen zu ihren Käufen erhalten.
Spezialangebote und Feiertagsaktivitäten: BookHarber bietet exklusive Rabatte und Aktionen während spezieller Veranstaltungen und Feiertagen an, um seine Kundenbasis zu binden und zu belohnen.
Kundendienst: Kunden können Support-Tickets eröffnen, um eventuell auftretende Bedenken oder Probleme zu klären, und erhalten prompte Unterstützung vom BookHarber-Team.
Kundenverwaltung: Mitarbeiter mit unterschiedlichen Rollen haben die Möglichkeit, verschiedene Aspekte der Plattform zu verwalten, wie z.B. Kundenkonten, Auftragsbearbeitung und Problemlösung.
Im BookHarber-Ökosystem können wir mehrere Schlüsselbenutzerrollen identifizieren, wie z.B.:
Gast: Nicht registrierte Benutzer, die die Website durchsuchen,
ach Büchern suchen und spezielle Angebote ansehen können.
Kunde: Registrierte Benutzer, die Bücher kaufen, Bestellungen verwalten, Logistik verfolgen und Supporttickets öffnen können.
Shop-Admin: Mitarbeiter, die für die allgemeine Verwaltung und den Betrieb der Plattform verantwortlich sind. Mit vollem Zugriff.
Büchermanager: Mitarbeiter, die für die Verwaltung von Büchern und Kategorien verantwortlich sind.
Kundenservicemitarbeiter: Mitarbeiter, die mit der Beantwortung von Supporttickets betraut sind.
Logistikdienstleister Dritter: Externe Partner, die für die Verwaltung und Verfolgung des Versands und der Lieferung von Bestellungen verantwortlich sind.
Marketingpersonal: Mitarbeiter, die für die Förderung von BookHarber verantwortlich sind, und für die Verwaltung von Sonderangeboten und Veranstaltungen zuständig sind.
Um das RBAC-System von Logto effektiv für BookHarber zu implementieren, müssen wir Bereiche entwerfen, die den verschiedenen REST-APIs entsprechen. Bereiche sind Berechtigungen, die das Zugriffslevel einer spezifischen Rolle für jeden API-Endpunkt definieren. Indem wir den entsprechenden Bereichen jede Benutzerrolle zuweisen, können wir sicherstellen, dass Benutzer
ur Zugang zu den Aktionen und Ressourcen haben, die für ihre Rolle relevant sind.
Lassen Sie uns Bereiche für die folgenden REST-APIs entwerfen:
Kategorien API:
create:categories: POST /categories
write:categories: PUT /categories/:id
delete:categories: DELETE /categories/:id
list:categories: GET /categories
Bücher API:
create:books: POST /books
write:books: PUT /books/:id
delete:books: DELETE /books/:id
list:books: GET /books
read:books: GET /books/:id
Kunden-API:
list:customers: GET /customers
write:customers: PUT /customers/:id
delete:customers: DELETE /customers/:id
read:customers: GET /customers/:id
Bestellungen API:
create:orders: POST /orders
list:orders: GET /orders
read:orders: GET /orders/:id
write:orders: PUT /orders/:id
Veranstaltungen API:
create:events: POST /events
write:events: PUT /events/:id
list:events: GET /events
delete:events: DELETE /events/:id
Bestellverfolgung API:
read:orderTracks: GET /orders/:id/tracks
create:orderTracks: POST /orders/:id/tracks
write:orderTracks: PUT /orders/:id/tracks/:trackId
Jetzt, wo wir die passenden Bereiche für jede REST-API definiert haben, können wir diese Bereiche den entsprechenden Benutzerrollen im BookHarber-Ökosystem zuweisen:
Bereiche
Gast
Kunde
Shop-Admin
Büchermanager
Kundendienstmitarbeiter
Logistikdienstleister Dritter
Marketingpersonal
create:categories
✓
✓
write:categories
✓
✓
delete:categories
✓
✓
list:categories
✓
✓
✓
✓
✓
✓
✓
create:books
✓
✓
write:books
✓
✓
delete:books
✓
✓
list:books
✓
✓
✓
✓
✓
✓
✓
read:books
✓
✓
✓
✓
✓
✓
✓
list:customers
✓
✓
write:customers
✓
delete:customers
✓
read:customers
✓
✓
create:orders
✓
✓
✓
✓
✓
✓
list:orders
✓
read:orders
✓
✓
write:orders
✓
create:events
✓
✓
write:events
✓
✓
list:events
✓
✓
✓
✓
✓
✓
✓
delete:events
✓
✓
read:orderTracks
✓
✓
✓
create:orderTracks
✓
✓
write:orderTracks
✓
✓
create:tickets
✓
✓
✓
✓
✓
✓
list:tickets
✓
✓
read:tickets
✓
✓
write:tickets
✓
✓
Verständnis der Unterschiede zwischen "list" und "read" Bereiche#
Um die Unterschiede zwischen "list" und "read" Bereichen im Kontext von REST-API-Design und RBAC weiter zu veranschaulichen, betrachten wir ein reales Beispiel, das sich auf einen Online-Buchladen, BookHarber, bezieht.
Nehmen wir an, BookHarber hat zwei Arten von Benutzern: Kunden und Kundendienstmitarbeiter. Kunden können Bestellungen aufgeben, während Kundendienstmitarbeiter dafür verantwortlich sind, Kunden bei ihren Bestellungen zu helfen. Lassen Sie uns einen Blick darauf werfen, wie "list" und "read" Bereiche auf die orders API-Ressource in diesem Szenario angewendet werden.
List-Bereiche: Ein "list" Bereich erlaubt es dem Benutzer, auf eine Sammlung von Entitäten im System zuzugreifen. Zum Beispiel erlaubt der list:orders Bereich es einem Benutzer, eine Liste aller verfügbaren Bestellungen abzurufen. Im Kontext von BookHarber könnte dieser Bereich für Ladenverwalter oder andere Mitarbeiter
ützlich sein, die einen Überblick über alle Bestellungen im System haben müssen. Allerdings sollten Kundendienstmitarbeiter
icht in der Lage sein, auf die gesamte Liste der Bestellungen zuzugreifen, da ihre Rolle darin besteht, individuelle Kunden bei ihren spezifischen Bestellungen zu unterstützen.
Read-Bereiche: Ein "read" Bereich gibt dem Benutzer die Erlaubnis, auf eine einzelne Entität mit einer gegebenen ID zuzugreifen. Zum Beispiel erlaubt der read:orders Bereich dem Benutzer, detaillierte Informationen über eine spezifische Bestellung anhand ihrer ID einzusehen. Im Falle von BookHarber ist dieser Bereich ideal für Kundendienstmitarbeiter, die Informationen über eine bestimmte Kundenbestellung benötigen. Wenn ein Kunde ein Supportticket öffnet, kann der Kundendienstmitarbeiter die im Ticket bereitgestellte Bestell-ID verwenden, um auf die Details dieser spezifischen Bestellung zuzugreifen.
Verständnis für Eigentum: Warum Kunden für ihre eigenen Bestellungen keine "read" oder "list" Bereiche benötigen#
In vielen Anwendungen ist es üblich, dass Benutzer Zugang zu ihren eigenen Ressourcen haben, ohne ihnen explizit die entsprechenden "read" oder "list" Bereiche zu gewähren. Dies liegt daran, dass Benutzer als Besitzer dieser Ressourcen angesehen werden und daher
atürlich Zugang zu ihnen haben sollten. Im Falle unseres BookHarber-Beispiels können Kunden Bestellungen aufgeben, besitzen aber
icht die "read:orders" oder "list:orders" Bereiche.
Das Konzept des Besitzes spielt eine entscheidende Rolle bei der Definition der Zugriffskontrolle für spezifische Ressourcen in einer REST-API. Indem wir anerkennen, dass Benutzer immer Zugang zu ihren eigenen Ressourcen haben können, können wir eine effizientere und sicherere Zugriffskontrolle implementieren, ohne unnötige Berechtigungen zu gewähren. Im Falle von BookHarber bedeutet dies, dass Kunden ihre Bestellungen weiterhin ansehen und verwalten können, ohne zusätzliche Bereiche zu benötigen.
Um zu demonstrieren, wie das funktioniert, betrachten wir den GET /orders Endpunkt:
Wenn ein Benutzer den list:orders Bereich hat (z.B. Ladenverwalter oder Mitarbeiter), kann er alle Bestellungen im System ansehen. Dies gibt ihnen einen umfassenden Überblick über die für ihre Rolle
otwendigen Bestelldaten.
Wenn ein Benutzer
icht den list:orders Bereich hat (z.B.
ormale Kunden), wird das System
ur die Bestellungen zurückgeben, die dem Benutzer gehören. Dies stellt sicher, dass Kunden weiterhin auf ihre Bestellinformationen zugreifen können, ohne unnötige Berechtigungen gewährt zu bekommen.
Durch die Implementierung dieser besitzbasierten Zugriffskontrolle kann die API den verschiedenen Benutzerrollen das geeignete Zugriffslevel bieten, während die Sicherheit und ein auf den Benutzer zugeschnittenes Erlebnis aufrechterhalten werden. Im Szenario von BookHarber ermöglicht das Besitzmodell den Kunden den Zugang zu ihren Bestellinformationen ohne die Notwendigkeit für "read:orders" oder "list:orders" Bereiche, was das Design der Zugriffskontrolle vereinfacht und das Gesamterlebnis des Benutzers verbessert.
Konfigurationseinstellungen in Logto Console vornehmen#
Um die Konfiguration in Logto's Konsole abzuschließen, folgen Sie diesen Schritten:
Erstellen einer Single Page Application (SPA) für React: Richten Sie eine SPA in der Logto-Konsole für Ihre React-Anwendung ein.
Erstellen einer API-Ressource: Fügen Sie eine
eue API-Ressource mit dem Identifikator https://api.bookharber.com hinzu.
Definieren von Bereichen für die Ressource: Erstellen Sie die
otwendigen Bereiche unter der
eu erstellten API-Ressource.
Erstellen von Rollen und Zuweisen von Bereichen: Definieren Sie die Benutzerrollen für Ihre Anwendung und weisen Sie jeder Rolle die passenden Bereiche zu.
Rollen Benutzern zuweisen: Weisen Sie den Benutzern in Ihrer Anwendung die relevanten Rollen zu, um sicherzustellen, dass jeder Benutzer (insbesondere Mitarbeiter) die richtigen Berechtigungen basierend auf seiner Rolle hat.
In unserem Beispielprojekt, BookHarber, verwenden wir Express für den Backend-Service und React für die Frontend-Webseite. Dieser Abschnitt wird einen kurzen Überblick darüber geben, wie wir die RBAC-Funktionen von Logto in diese beliebten Technologien integrieren können, um unsere Anwendung zu sichern.
Logto's RBAC-System ist ein leistungsstarkes Werkzeug für die Verwaltung der Zugriffskontrolle und Sicherheit in modernen Anwendungen. Durch die Nutzung der RBAC-Funktionen von Logto können Sie sicherstellen, dass Benutzer einen angemessenen Zugang zu Ressourcen auf der Grundlage ihrer Rollen haben, und schützen sensible Daten und Funktionen vor unberechtigtem Zugang.
In diesem Artikel haben wir ein reales Beispiel eines Online-Buchladens, BookHarber, untersucht und gezeigt, wie man Bereiche entwirft, ihnen Benutzerrollen zuweist und die RBAC-Funktionen von Logto sowohl im Frontend als auch im Backend der Anwendung implementiert.
Indem Sie diese Konzepte und Techniken in Ihren Projekten anwenden, können Sie die Sicherheit und Zugriffskontrolle Ihrer Anwendungen verbessern und ein
ahtloses und sicheres Benutzererlebnis bieten. Ob Sie an einer E-Commerce-Plattform, einem Content-Management-System oder einem anderen Projekt mit rollenbasierter Zugriffskontrolle arbeiten, das RBAC-System von Logto bietet eine flexible und effiziente Lösung für Ihre Zugriffskontrollanforderungen.
