Benutzer und Rollen

Benutzer

Ein Benutzer in OctoMesh repräsentiert eine Identität, die sich authentifizieren und auf Plattformressourcen zugreifen kann. Benutzer sind auf einen Tenant beschränkt — dieselbe Person kann in verschiedenen Tenants separate Benutzerkonten haben.

Benutzereigenschaften

Eigenschaft	Beschreibung
UserId	Eindeutige Kennung (automatisch generiert)
Name	Benutzername für die Anmeldung
Email	E-Mail-Adresse (eindeutig innerhalb des Tenants)
FirstName / LastName	Optionaler Anzeigename
ExternalLogins	Verknüpfte Konten externer Identity Provider
ResetPasswordOnLogin	Erzwingt eine Passwortänderung bei der nächsten Anmeldung

Benutzertypen

Lokale Benutzer authentifizieren sich mit einem in der Datenbank des Tenants gespeicherten Benutzernamen und Passwort.

Externe Benutzer authentifizieren sich über einen Identity Provider (Google, Azure AD, LDAP usw.). Bei der ersten Anmeldung über einen externen Provider erstellt OctoMesh einen lokalen Benutzerdatensatz, der mit der externen Identität verknüpft ist.

Tenantübergreifende Benutzer authentifizieren sich über einen übergeordneten Tenant. Ihrem Benutzernamen wird xt_{parentTenantId}_ vorangestellt, um sie von lokalen Benutzern zu unterscheiden. Siehe Tenantübergreifende Authentifizierung.

Benutzer erstellen

Benutzer können auf drei Arten erstellt werden:

1. Über die CLI — ein Administrator erstellt den Benutzer mit einem Passwort:

   octo-cli -c CreateUser -un "john.doe" -e "john@example.com" -p "SecurePass123"

2. Selbstregistrierung — ein Benutzer meldet sich zum ersten Mal über einen externen Identity Provider an. Beim Provider muss AllowSelfRegistration aktiviert sein (Standard: true).

3. Admin-Provisionierung — ein Systemadministrator provisioniert eine tenantübergreifende Benutzerzuordnung, bevor sich der Benutzer zum ersten Mal anmeldet. Siehe Tenantübergreifende Authentifizierung.

Passwortverwaltung

# Reset a user's password
octo-cli -c ResetPassword -un "john.doe" -p "NewPassword456"

Das Flag ResetPasswordOnLogin kann gesetzt werden, um Benutzer zu zwingen, ihr Passwort bei der nächsten Anmeldung zu ändern.

Rollen

Rollen definieren Berechtigungen in OctoMesh. Dienste prüfen die Rollen-Claims im Access Token des Benutzers, um Operationen zu autorisieren.

Standardrollen

Jeder neue Tenant wird mit 10 Standardrollen bereitgestellt:

Rolle	Zweck
TenantManagement	Tenants erstellen, konfigurieren und löschen
UserManagement	Benutzer, Rollen, Gruppen und Identity Provider verwalten
CommunicationManagement	Kommunikationsadapter und Deployment Sites konfigurieren
Development	Zugriff auf Entwicklungsfunktionen (z. B. GraphQL-Playground)
AdminPanelManagement	Zugriff auf Verwaltungs-/Admin-Funktionen in Refinery Studio (Systemkonfiguration, Repository-Administration). Beibehaltener Name des stillgelegten Admin Panels.
BotManagement	Geplante Jobs konfigurieren und verwalten
DashboardManagement	Dashboards erstellen und bearbeiten
DashboardViewer	Dashboards anzeigen (nur lesend)
ReportingManagement	Berichte erstellen und verwalten
ReportingViewer	Berichte anzeigen (nur lesend)

Rollenzuweisung

Rollen können Benutzern auf zwei Arten zugewiesen werden:

1. Direkte Zuweisung — ein Administrator weist einem Benutzer explizit eine Rolle zu:

   octo-cli -c AddUserToRole -un "john.doe" -r "DashboardViewer"

2. Gruppenmitgliedschaft — der Benutzer erbt alle Rollen aus den Gruppen, denen er angehört. Siehe Gruppen.

Effektive Rollen

Die effektiven Rollen eines Benutzers sind die Vereinigung von:

• Direkt zugewiesenen Rollen
• Rollen, die aus allen Gruppenmitgliedschaften geerbt werden (einschließlich verschachtelter Gruppen, bis zu 10 Ebenen tief)

Der Identity Service löst die effektiven Rollen zum Zeitpunkt der Token-Ausstellung auf und nimmt sie als role-Claims in das JWT-Access-Token auf.

Rollen für Clients

Rollen sind nicht auf Benutzer beschränkt. Auch einem OAuth-Client (Maschine-zu-Maschine-Identität) können Rollen zugewiesen werden — direkt oder über Gruppenmitgliedschaft — und sein client_credentials-Access-Token trägt dann die aufgelösten role-Claims in derselben Form wie ein Benutzer-Token. Dadurch kann ein Dienst rollengeschützte Endpunkte aufrufen. Siehe Client-Rollen und Gruppenmitgliedschaft.

Rollen verwalten

# List all roles
octo-cli -c GetRoles

# Create a custom role
octo-cli -c CreateRole -n "DataAnalyst"

# Assign role to user
octo-cli -c AddUserToRole -un "john.doe" -r "DataAnalyst"

# Remove role from user
octo-cli -c RemoveUserFromRole -un "john.doe" -r "DataAnalyst"

# Delete a role
octo-cli -c DeleteRole -n "DataAnalyst"

Access Tokens

Wenn sich ein Benutzer authentifiziert, stellt der Identity Service ein JWT-Access-Token aus, das Folgendes enthält:

Claim	Beschreibung
sub	Benutzer-ID
preferred_username	Benutzername
tenant_id	Der Tenant, in den sich der Benutzer angemeldet hat
allowed_tenants	Liste der Tenants, auf die der Benutzer zugreifen darf
role	Liste der effektiven Rollen (direkt + über Gruppen geerbt)
home_tenant_id	Für tenantübergreifende Benutzer: ihr Home-Tenant (übergeordneter Tenant)

Dienste validieren den allowed_tenants-Claim gegen die {tenantId} im Anfragepfad. Client-Credentials-Tokens (Dienst-zu-Dienst, ohne sub-Claim) umgehen die Tenant-Validierung.