Zielgruppe & Rolle

Rolle: IT-Administrator / Kunden-Admin | Voraussetzung: OIDC / Microsoft Entra ID Anbindung eingerichtet

Berechtigungskonzept

Das Berechtigungskonzept der ConnectCLOUD basiert auf einer mandantenbezogenen Zugriffskontrolle und einer rollenbasierten Berechtigungssteuerung (RBAC).

Architektur-Übersicht

Das folgende Diagramm illustriert den Autorisierungsprozess:

Mandanten-basierte Zugriffskontrolle

Der Zugriff auf einen Mandanten wird über E-Mail-Regex-Regeln gesteuert. Jeder Mandant kann eine Liste von regulären Ausdrücken definieren (allowedEmailRegex). Wenn die E-Mail-Adresse eines angemeldeten Benutzers auf einen dieser Ausdrücke passt, erhält der Benutzer Zugriff auf diesen Mandanten.

Konfiguration

Die Konfiguration erfolgt im Portal unter Administration > Berechtigungen. Hier können pro Zeile reguläre Ausdrücke hinterlegt werden.

• Beispiel: (?i)^.*@mbcom\.de$ erlaubt allen Benutzern mit einer mbcom.de E-Mail-Adresse den Zugriff.

Login-Routing vs. Autorisierung

allowedEmailRegex erfüllt zwei getrennte Aufgaben, die technisch unterschiedlich umgesetzt sind:

1. Login-Routing (Domain-Index): Aus dem literalen Domain-Anteil jedes allowedEmailRegex-Musters wird eine abgeleitete, kundenübergreifende Index-Datei (customers/login-domains.json) erzeugt. Anhand dieses Index entscheidet der Login-Bildschirm bereits vor der Weiterleitung an den Identity-Provider, zu welchem Kunden eine eingegebene E-Mail-Adresse gehört – per exaktem, case-insensitivem Abgleich der Domain, nicht per Regex-Scan über alle Kunden. Das verhindert, dass die (ggf. zu weit gefasste) Konfiguration eines Kunden einen Benutzer eines anderen Kunden zum falschen Identity-Provider schickt.
2. Autorisierung (Regex-Prüfung): Nach dem erfolgreichen Login beim Identity-Provider wird die tatsächliche E-Mail-Adresse aus dem Token (claims.Email) weiterhin vollständig gegen die allowedEmailRegex-Muster der Mandanten des zugeordneten Kunden geprüft. Diese Prüfung bleibt unverändert die einzige Zugriffsschranke.

Eine Domain darf innerhalb der Mandanten eines Kunden beliebig oft wiederverwendet werden (z. B. wenn mehrere Mandanten dieselbe Firmen-Domain zulassen sollen) – der Index fasst das zu einem Eintrag zusammen. Beansprucht dagegen ein anderer Kunde dieselbe Domain, wird das Speichern der Mandanten- bzw. Kundenkonfiguration mit einer eindeutigen Fehlermeldung abgelehnt; existiert ein solcher Konflikt dennoch in den gespeicherten Daten (z. B. durch einen manuellen Eingriff), verweigert der Login für diese Domain, statt einen der beiden Kandidaten zu erraten. Der Benutzer sieht dabei dieselbe allgemeine Login-Fehlermeldung wie bei jeder anderen fehlgeschlagenen Kundenzuordnung; im Protokoll wird die Ablehnung jedoch mit der eigenen Kategorie ambiguous_login_domain samt der beteiligten Kundennummern festgehalten.

Der Index wird automatisch aktualisiert, sobald sich die Domain-Zuordnung tatsächlich ändert: beim Speichern, Löschen oder Umbenennen eines Mandanten sowie beim Löschen oder Umbenennen eines Kunden. Reine Änderungen an den Kundendaten (z. B. Notfallkontakte) lösen keine Aktualisierung aus, da die Login-Domains ausschließlich aus den Mandanten abgeleitet werden. Portal-Administratoren können den Index zusätzlich über GET /api/registry/v1/admin/login-domains einsehen (inkl. erkannter Konflikte) und über POST /api/registry/v1/admin/login-domains/rebuild vollständig neu aufbauen.

Rollen und Berechtigungen

Berechtigungen werden in ConnectCLOUD differenziert auf zwei Ebenen gesteuert:

1. Kunden-Ebene (CUSTOMER_ADMIN): Übergreifende Administration für das gesamte Kundenkonto (Stammdaten, Benachrichtigungseinstellungen, Notfall-Wiederherstellung, Einmalcodes und kundenweite Administrator-Gruppen).
2. Mandanten-Ebene (TENANT_*): Spezifische Berechtigungen und Zugriffsrollen für einzelne Mandanten.

Verfügbare Rollen

Rolle	Ebene	Beschreibung	Wichtigste Berechtigungen
CUSTOMER_ADMIN	Kunde	Kundenweiter Administrator mit Vollzugriff auf übergreifende Einstellungen und Notfallwiederherstellung.	customer:settings:read, customer:settings:write
TENANT_ADMIN	Mandant	Mandanten-Administrator mit vollem Schreibzugriff auf Mandanten-Einstellungen, Token-Generierung, Rechnungsvergleich sowie administrativer Steuerung von Workflow-Instanzen.	settings:read, settings:write, invoice:compare:run, invoice:compare:read, workflow:admin
TENANT_ADMIN_VIEWER	Mandant	Lesender Zugriff auf Mandanten-Einstellungen.	settings:read
TENANT_DATA_VIEWER	Mandant	Standardzugriff plus Lesezugriff auf microtech-Daten, OpenSearch-Indizes und USt-ID-Prüfergebnisse.	tenant:access, tenant:microtech-data:read, tenant:opensearch:read, tenant:vat-validation:read
TENANT_VAT_VIEWER	Mandant	Basis-Zugriff plus Einsicht in die USt-ID-Prüfung über die eingebetteten Ansichten aus microtech (/embedded/vat-validation/…) sowie das Auslösen einzelner Prüfungen für Adressen und Vorgänge – ohne Zugriff auf sonstige microtech-Daten (z. B. Umsätze) und ohne die regulären Portalseiten. Mandantenweite Stapelprüfungen bleiben Administratoren vorbehalten.	tenant:access, tenant:vat-validation:read, tenant:vat-validation:run
TENANT_VIEWER	Mandant	Basis-Zugriff auf den Mandanten und die Beleg-/Workflow-Bearbeitung.	tenant:access
PORTAL_ADMIN	System	Globaler System-Administrator von MBCOM mit uneingeschränktem Zugriff auf alle Mandanten und Systemeinstellungen.	* (Volle Systemrechte)

Auf Mandantenebene kann eine Gruppe mehreren Rollen zugeordnet sein; ein Benutzer erhält die Vereinigung aller Rollen seiner Gruppen. In der Konfiguration (groupRoleMapping) steht pro Gruppe entweder eine einzelne Rolle als Zeichenkette oder eine Liste von Rollen.

Wie wird die Rolle CUSTOMER_ADMIN ermittelt?

Die Rolle CUSTOMER_ADMIN wird dynamisch vom System nach folgenden Kriterien vergeben:

1. Verifizierter Recovery-Kontakt: Benutzer, deren E-Mail-Adresse im Reiter Sicherheit der Kunden-Administration als bestätigte Notfalladresse hinterlegt ist, erhalten bedingungslos CUSTOMER_ADMIN.
2. Kundenweites Gruppen-Mapping: Wenn Sicherheitsgruppen der Rolle CUSTOMER_ADMIN zugewiesen sind, erhalten alle Gruppenmitglieder die Rolle.
3. Automatischer Fallback: Ist keine kundenweite Gruppen-Zuordnung hinterlegt, greift zur Gewährleistung der Abwärtskompatibilität ein automatischer Fallback: Alle Benutzer mit der Rolle TENANT_ADMIN auf mindestens einem Mandanten erhalten ebenfalls Zugriff auf die Kunden-Administration.

Mandantenspezifisches Gruppen-Mapping

In den Mandanten-Einstellungen (Administration > Berechtigungen) legen Sie fest, welche OIDC-Gruppe (Object ID aus Entra ID) welcher internen Rolle für den gewählten Mandanten zugeordnet wird. Dies ermöglicht eine flexible Steuerung basierend auf bestehenden Berechtigungsgruppen Ihrer Organisation.

Mandantenweite Workflow-Administration (workflow:admin)

Um betriebliche Prozesse abzusichern und die Vertraulichkeit von Prüfpfaden zu gewährleisten, wird die administrative Steuerung von Workflow-Instanzen über eine dedizierte Berechtigung gesteuert:

• Exklusive Rollenzuordnung: Die Berechtigung workflow:admin ist strikt und ausschließlich der Rolle TENANT_ADMIN zugewiesen.
• Ausschluss für System- und Portal-Administratoren: Die Rolle PORTAL_ADMIN erhält workflow:admin standardmäßig nicht. Portal-Administratoren können Workflow-Instanzen eines Kunden nur dann einsehen oder verwalten, wenn ihnen explizit die Rolle TENANT_ADMIN für den jeweiligen Mandanten zugewiesen wurde. Dadurch bleibt die Trennung zwischen System-Hosting und Mandantendaten gewahrt.
• Enthaltene Verwaltungsfunktionen:
  • Zentraler Instanzenüberblick: Einsicht in sämtliche aktiven, abgeschlossenen, genehmigten, abgelehnten und abgebrochenen Workflow-Instanzen des Mandanten über den Tab Alle Workflow-Instanzen in der Aufgabenübersicht – unabhängig von der persönlichen Entra-Gruppenzugehörigkeit.
  • Administrativer Workflow-Abbruch: Berechtigung zur außerordentlichen Beendigung verwaister oder blockierter Workflows (POST /api/workflow/v1/tasks/:id/cancel) inklusive automatischer Entsperrung des Vorgangs in microtech ERP und revisionssicherem Audit-Protokoll.

Mandantenwechsel

Ein Benutzer kann zwischen den Mandanten wechseln, auf die er Zugriff hat.

1. Mandantenauswahl: Links oben im Portal befindet sich der Mandantenumschalter.
2. URL-Parameter: Über den Query-Parameter ?tenant=<mandantename> kann ein Wechsel direkt beim Aufruf einer Seite ausgelöst werden.
3. Session-Aktualisierung: Beim Wechsel eines Mandanten wird ein neues Session-Token (JWT) ausgestellt, das die spezifischen Rollen und Berechtigungen für den Zielmandanten enthält.

---

Nächster Schritt in der Basiskonfiguration

Nachdem das Berechtigungskonzept definiert ist, richten Sie die Schnittstelle zu microtech büro+ ein: microtech Basis-Konfiguration

Zurück zur Übersicht: Basiskonfiguration Übersicht