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 und Rechnungsvergleich.	settings:read, settings:write, invoice:compare:run, invoice:compare:read
TENANT_ADMIN_VIEWER	Mandant	Lesender Zugriff auf Mandanten-Einstellungen.	settings:read
TENANT_DATA_VIEWER	Mandant	Standardzugriff plus Lesezugriff auf microtech-Daten und OpenSearch-Indizes.	tenant:access, dataview:read
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)

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.

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