Identität und rollenbasierte Zugriffskontrolle — die Grundlage von Zero-Trust. Integriert sich mit Ihrem bestehenden Identity Provider und beschränkt Berechtigungen bis auf einzelne Dokumente und Tools.

Identity Provider

StellarBase integriert sich über Standardprotokolle mit jedem gängigen Identity Provider:

Protokoll	Typische IdPs
SAML 2.0	Okta, Azure AD, ADFS, Google Workspace, Auth0, Keycloak, Ping
OIDC	Dasselbe — die meisten IdPs unterstützen beides
SCIM 2.0	Automatisiertes Provisioning von Benutzern / Gruppen aus Okta, Azure AD usw.
LDAP / Active Directory	Direktes Binding für On-Premise-Bereitstellungen

Für Organisationen ohne IdP (kleine Teams, Pilotprojekte) steht lokale passwortbasierte Authentifizierung + MFA zur Verfügung, wird aber für den Produktivbetrieb nicht empfohlen.

MFA

Die Multi-Faktor-Authentifizierung wird über Ihren IdP erzwungen. StellarBase respektiert die MFA-Assertion aus SAML/OIDC-Tokens. Für sensible Aktionen (Admin-Operationen, Massenexporte) kann auch innerhalb einer aktiven Session eine erneute Step-up-Authentifizierung verlangt werden.

Rollenhierarchie

Drei Ebenen:

1. Organisation — übergeordnete Abrechnung + SSO-Konfiguration + globaler Admin
2. Base — Inhalte, Agenten, Workflows für ein Projekt / einen Fall / eine Abteilung
3. Ressource — einzelne Dokumente, Sammlungen, Agenten, Tools

Die effektive Berechtigung eines Benutzers ist die Schnittmenge aus Organisationsrolle, Base-Rolle und Ressourcen-ACL.

Standardrollen

Organisationsebene

Rolle	Berechtigungen
Owner	Alles — Abrechnung, SSO, Benutzer-Lebenszyklus, alle Bases
Admin	Alles außer Abrechnung und Eigentumsübertragung
User	Eigene Bases erstellen, eingeladenen Bases beitreten

Base-Ebene

Rolle	Berechtigungen
Base-Admin	Datenquellen, Agenten, Workflows, Mitglieder verwalten; Audit-Log einsehen
Editor	Inhalte lesen + schreiben, Agenten konfigurieren, Workflows auslösen
Reviewer	Lesen + kommentieren + HITL-Gates freigeben; keine Änderungen möglich
Viewer	Nur-Lese-Zugriff auf bestimmte Sammlungen
External	Zeitlich begrenzter, eng beschränkter Zugriff

Benutzerdefinierte Rollen

Definieren Sie Ihre eigene Rolle mit einer spezifischen Berechtigungsmatrix. Beispiele:

• Senior Reviewer — Reviewer + Fähigkeit, HITL-Ablehnungen zu überstimmen
• Analyst — Editor minus Agenten-Konfiguration (Analysten nutzen Agenten, optimieren sie aber nicht)
• Compliance Officer — Base-übergreifender Lesezugriff auf das Audit-Log + Schreibzugriff auf Richtlinienkonfiguration

Benutzerdefinierte Rollen werden als JSON-Richtlinien definiert; der Richtlinieneditor bietet Autovervollständigung für jede verfügbare Berechtigung.

ACLs auf Ressourcenebene

Jede Rolle auf Base-Ebene kann pro Ressource überschrieben werden. Häufige Muster:

• Als „privileged“ markierte Dokumente sind unabhängig von der Base-Rolle nur für eine benannte Liste von Benutzern sichtbar
• Ein bestimmter Agent kann nur von Benutzern einer benannten Gruppe aufgerufen werden
• Ein bestimmter Workflow kann nur von Admins ausgelöst werden

Berechtigungsvererbung

Sammlungen erben von Bases. Dokumente erben von Sammlungen. Tags und ACLs pro Dokument können die Vererbung überschreiben — immer einschränkend, niemals erweiternd.

Berechtigungen aus dem Quellsystem

Konnektoren können Berechtigungen aus dem Quellsystem durchreichen:

• Google Drive, SharePoint, Box: native ACL bleibt erhalten. Ein Dokument, das ein Benutzer in Drive nicht lesen kann, ist ein Dokument, das er auch in StellarBase nicht lesen kann.
• Datenbanken: Sicherheit auf Zeilenebene über konfigurierte Spaltenfilter
• Benutzerdefiniert: Sie stellen das Berechtigungs-Mapping bereit

Agenten-Berechtigungen

Agenten sind ebenfalls Principals. Die Berechtigungen eines Agenten sind die Schnittmenge aus:

• dem Benutzer, der ihn aufgerufen hat (bei interaktiven Aufrufen)
• dem konfigurierten Wissensbereich des Agenten
• der Tool-Allowlist des Agenten

Das bedeutet, ein Agent kann niemals mehr sehen als der Benutzer, der ihn aufruft — selbst wenn der Agent technisch mit umfassenderem Zugriff konfiguriert ist.

Servicekonten

Erstellen Sie für API-Integrationen Servicekonten mit beschränkten API-Schlüsseln. Jedes Servicekonto verfügt über:

• einen Satz von Berechtigungen (dasselbe Modell wie bei Benutzern)
• ein Rate-Limit
• ein optionales Ablaufdatum
• eine IP-Allowlist

Externe Benutzer

Laden Sie Benutzer außerhalb Ihrer Organisation mit eng beschränktem Zugriff ein:

• Geltungsbereich: eine einzelne Base, eine einzelne Sammlung oder ein einzelnes Dokument
• Dauer: standardmäßig 7 Tage, konfigurierbar
• Authentifizierung: SAML/OIDC aus deren IdP oder E-Mail + Verifizierungscode
• Audit: alle ihre Aktionen werden mit dem Flag external=true protokolliert

Session-Verwaltung

• Standard-Lebensdauer einer Session: 12 Stunden
• Refresh-Tokens werden für aktive Benutzer automatisch verlängert
• Admins können alle aktiven Sessions sofort widerrufen
• Erneute Step-up-Authentifizierung für risikoreiche Aktionen erforderlich

Audit

Jedes Auth-Ereignis wird protokolliert: Login, Logout, MFA-Challenge, Berechtigungsänderung, Rollenzuweisung, fehlgeschlagene Autorisierung. Siehe Audit-Log.

Verwandt

• Zero-Trust
• Audit-Log
• Zusammenarbeit