Zum Hauptinhalt springen
DuoKey Cockpit — one shared platformtenant resolved from the signed token — cannot be forgedTenant AisolatedKeysAccess policiesAudit trailOrganizational unitsFinance · Engineering · …Tenant BisolatedKeysAccess policiesAudit trailTenant CisolatedKeysAccess policiesAudit trail
Every record carries a tenant id; the tenant comes from the signed token, and isolation is enforced at the data layer — with organizational units for in-tenant scoping.
Gilt für:
Cockpit v2Row-level multi-tenancyHost-managed tenants

Das Mandantenfähigkeitsmodell​

Cockpit v2 ist konstruktionsbedingt mandantenfähig. Jede Anfrage läuft im Sicherheitskontext eines authentifizierten Mandanten, und der gesamte Datenzugriff wird automatisch auf diesen Mandanten gefiltert. Da die Mandantenidentität aus der signierten Sitzung abgeleitet wird, kann sie von einem Client nicht gefälscht werden.

Konstruktionsbedingte Isolation

Der Datenzugriff ist auf der Datenschicht der Plattform auf den Mandanten beschränkt, statt einzelnen Funktionen zur Durchsetzung überlassen zu werden.

Zwei Scoping-Ebenen

Organisationseinheiten fügen einen zweiten, mandanteninternen Umfang hinzu, sodass Teams und Abteilungen innerhalb eines Mandanten isoliert werden können.

Edition-getriebene Berechtigungen

Was ein Mandant tun kann, wird durch seine zugewiesene Edition bestimmt — es gibt keine mandantenspezifischen Feature-Überschreibungen.

Der Mandantendatensatz​

AttributZweck
Eindeutiger NameEin eindeutiger Bezeichner für den Mandanten
AnzeigenameWie der Mandant dargestellt wird
Administrator-KontaktPrimäre Administrator-E-Mail
EditionDie zugewiesene Edition, die Funktionen und Limits bestimmt
AbonnementAbrechnungsvereinbarung (Pay-as-you-go, monatlich, jährlich, individuell oder kostenlos)
TestzustandOb sich der Mandant in einer Testphase befindet und wann diese endet
Aktiver ZustandOb der Mandant aktiviert ist

Lebenszyklus​

1

Erstellen

Ein Host-Administrator erstellt den Mandanten mit seinem Slug, Namen, der Admin-E-Mail und der Edition. Der Mandant startet aktiv und in der Testphase; die Erstellung wird in den Audit- und Aktivitätsprotokollen festgehalten.

2

Administrator bereitstellen

Für den neuen Mandanten wird ein erster Administrator bereitgestellt, sodass er unabhängig verwaltet werden kann.

3

Betreiben

Der Mandant kann aktiviert oder deaktiviert, seine Benutzer verwaltet und seine Edition innerhalb der Kompatibilitätsgrenzen neu zugewiesen werden.

4

Löschen

Die Löschung ist weich (soft) — der Datensatz bleibt für Audit-Zwecke erhalten und kann von der aktiven Nutzung ausgeschlossen werden.

Edition-Neuzuweisung ist abgesichert

Ein Mandant kann nur zu einer Edition wechseln, in die seine aktuelle Nutzung bereits passt — kein Kontingent überschritten, kein genutztes Modul deaktiviert, keine nun nicht mehr verfügbare Ressourcenart vorhanden. Alle Verstöße werden gemeinsam gemeldet. Siehe Editionen.

Organisationseinheiten​

Innerhalb eines Mandanten bilden Organisationseinheiten einen Baum, der Ressourcen und Rollenzuweisungen auf Teams oder Abteilungen beschränkt. Eine App (und andere Ressourcen) kann an eine OU gebunden werden; eine leere OU bedeutet, dass die Ressource mandantenweit sichtbar ist. Siehe Administration → Organisationseinheiten.

Hostverwaltete Administration​

Die Mandantenverwaltung ist eine Fähigkeit auf Host-Ebene — das Erstellen und Konfigurieren von Mandanten, das Aktivieren oder Deaktivieren, die Neuzuweisung von Editionen und die Durchführung der hostseitigen Benutzer-Wiederherstellung (etwa das Entsperren von Konten oder das Zurücksetzen von MFA). Diese Aktionen sind innerhalb eines gewöhnlichen Mandanten nicht verfügbar, und Wiederherstellungsaktionen werden getrennt von Impersonation protokolliert, damit sensible Operationen nachvollziehbar bleiben.

API-Referenz
Detaillierte API-Endpunkte sind separat in den Entwicklerdokumenten → Plattform-Administrations-API dokumentiert.