Zum Hauptinhalt springen

Organisationstemplate konfigurieren

Wir werden den Prozess der Konfiguration der Organisationstemplate-Funktion über die Logto-Konsole durchgehen.

Navigiere zuerst zu Konsole > Organisationstemplate. Du wirst sehen, dass das Organisationstemplate aus zwei Teilen besteht: Organisationsrollen und Organisationsberechtigungen. Ein Organisationstemplate definiert gemeinsame Zugangskontrollrichtlinien (Berechtigungen und Rollen) für mehrere Organisationen.

Konfiguration über die Logto-Konsole​

Organisationsberechtigung erstellen​

Organisationsberechtigungen sind ein wesentlicher Bestandteil des Organisationstemplates. Diese Berechtigungen sind speziell für Organisationen innerhalb deines Produkts konzipiert. So verwaltest du sie:

  • Finde den Tab für Organisationsberechtigungen: Gehe zum Tab "Organisationsberechtigungen", um deine vorhandenen Berechtigungen zu sehen.
  • Hinzufügen, löschen und bearbeiten: Du kannst problemlos neue Organisationsberechtigungen hinzufügen, nicht benötigte löschen und bestehende Berechtigungen nach Bedarf bearbeiten.

Organisationsrolle erstellen​

Logto unterstützt zwei Arten von Organisationsrollen, dies entspricht dem Benutzer/System-Level RBAC:

  • Benutzer: Rollen, die Benutzern zugewiesen werden.
  • Maschine-zu-Maschine: Rollen, die Maschine-zu-Maschine-Anwendungen zugewiesen werden.

Logto ermöglicht es dir, Organisationsrollen auf verschiedene Weise zu definieren, um der Struktur deines Systems gerecht zu werden:

Nur Organisationsrollen mit Organisationsberechtigungen​

  • Wann verwenden: Du hast separate Benutzer/System-Endpunkte und Organisationsendpunkte.
  • Erklärung: Dies ist der einfachste Ansatz, wenn die technische Architektur und das API-Design deines Produkts Benutzer/System-Ressourcen klar von Organisationsressourcen trennen. Deine Organisationsrollen werden nur die Berechtigungen enthalten, die du für die Organisation definierst.

Nur Organisationsrollen mit API-Berechtigungen​

  • Wann verwenden: Benutzer/System-Level und Organisations-Level Zugangskontrolle werden durch dieselben Endpunkte gehandhabt.
  • Erklärung: Wähle dies, wenn du alle Berechtigungen über einheitliche API-Ressourcen verwalten möchtest.

Gemischte API- und Organisationsberechtigungen in Organisationsrollen​

  • Wann verwenden: Du hast separate Endpunkte für dein Produkt für Benutzer/System-Level und Organisations-Level definiert, aber einige Benutzerrollen erfordern eine Mischung aus beiden Benutzer-Level- und Organisations-Level-Berechtigungen.
  • Erklärung: Dies bietet die größte Flexibilität, kann aber auch am komplexesten zu verwalten sein.

Konfiguration über die Logto Management API​

Alles, was du in der Konsole tun kannst, kann auch über die Management API durchgeführt werden, einschließlich: Verwaltung des Organisationstemplates zum Erstellen, Löschen oder Bearbeiten von Organisationsberechtigungen und -rollen.

Für eine vollständige Liste der Fähigkeiten, siehe bitte unsere API-Referenz:

Mit der Logto Management API kannst du benutzerdefinierte Organisationserfahrungen erstellen, wie z. B. das Ermöglichen von Selbstbedienung für Organisationsadministratoren zur Erstellung von Organisationen. Sieh dir diesen Abschnitt an, um mehr Organisation-Level-Funktionen und -Verwaltung zu aktivieren.

Umgang mit Änderungen der Mitgliederberechtigungen​

Ähnlich wie bei API RBAC können Mitgliederberechtigungen während einer Sitzung geändert werden – zum Beispiel können ihnen neue Rollen zugewiesen oder bestehende Rollenberechtigungen geändert werden.

Was passiert, wenn sich die Mitgliederberechtigungen ändern? Es gibt zwei Fälle.

Keine neuen Berechtigungen im System eingeführt​

Aktuelle Organisationstokens (auch bekannt als Organisationstoken) bleiben gültig, bis sie ablaufen, selbst nachdem die Organisationsberechtigungen eines Benutzers geändert wurden. Neue Berechtigungen werden jedoch in nachfolgenden Organisationstokens widergespiegelt, und alle widerrufenen Berechtigungen werden weggelassen.

hinweis

Organisationstokens haben eine feste Ablaufzeit, die nicht geändert werden kann, im Gegensatz zu generischen Zugangstokens.

Rufe regelmäßig Logto Management API Endpunkte auf oder stelle eine langlebige Verbindung her (z. B. mit WebSocket), um die Organisationsberechtigungen des Benutzers dynamisch abzurufen. Bei Erkennung von Änderungen lösche das bestehende Organisationstoken, und neu ausgestellte Tokens werden automatisch die Änderungen im Berechtigungsumfang der Organisation widerspiegeln.

curl \
 -X GET https://[tenant_id].logto.app/api/organizations/{id}/users/{userId}/scopes \
 -H "Authorization: Bearer $ORGANIZATION_TOKEN"

Wenn Berechtigungsänderungen erkannt werden, lösche zuerst das Organisationstoken aus dem Speicher und rufe dann die SDK-Methode getOrganizationToken(organizationId) auf, um ein neues zu erhalten. Neu ausgestellte Organisationstokens sollten die Berechtigungsänderungen widerspiegeln.

Neue Berechtigung wird im System eingeführt und einem Mitglied zugewiesen​

Dies geschieht, wenn neue Berechtigungen in dein Organisationstemplate eingeführt werden. In diesem Fall musst du zuerst die neu eingeführten Berechtigungsumfänge beim Initialisieren des Logto-Clients einbeziehen. Zum Beispiel:

new LogtoClient({
  appId: 'your-app-id',
  redirectUrl: 'your-redirect-url',
  scopes: [
    'urn:logto:scope:organizations',
    // ... deine anderen bestehenden Organisationsberechtigungsumfänge,
    'new-organization-permission-scope',
  ],
});

Zweitens muss jede deiner Client-Anwendungen die Benutzer erneut um Zustimmung bitten oder sie erneut anmelden, um die neue Berechtigungsänderung zu erhalten. Dann wird der neue Berechtigungsumfang in neuen Organisationstokens widergespiegelt.

Codebeispiel für erneute Zustimmung:

signIn({ redirectUrl: 'your-redirect-url', prompt: 'consent' });