Im Auslieferungszustand ist die Anwendung nicht mandantenfähig.
Ohne aktivierte Mandantenfähigkeit arbeitet das System mit einem globalen Mandanten (im Weiteren Standard-Mandant genannt), unter dem alle Daten gemeinsam verwaltet werden.
Die Mandantenfähigkeit kann über den Konfigurationsparameter
deployment.singleTenantMode aktiviert werden.
Wird die Mandantenfähigkeit aktiviert, können Daten mandantenspezifisch administriert werden.
Jeder Mandant kann zudem eigene Einstellungen, Berechtigungen oder Dokumententypen für seine Benutzer festlegen, um das Verhalten und Erscheinungsbild der Anwendung an seine Anforderungen anzupassen.
Das Anlegen von Mandanten ist nur in der selbst gehosteten signoSign/Universal-OnPrem-Variante möglich.
Von einer Änderung des Modus der Mandantenfähigkeit in bestehenden Systemen wird abgeraten. In solchen Fällen wird stattdessen empfohlen, ein neues System aufzusetzen.
Aktivierung der Mandantenfähigkeit
Um die Mandantenfähigkeit zu aktivieren muss die Einstellung deployment.singleTenantMode auf false gestellt werden. Damit ändern sich auch die notwendigen Rollen, die ein Benutzer benötigt, um sich an der Anwendung anmelden zu können.
In der Installationsanleitung wird beschrieben, dass ein konfigurierter Benutzer eine der Rollen ssu-user oder ssu-admin benötigt, um für die Nutzung der Anwendung berechtigt zu sein. Beim ersten Start der Anwendung werden diese Rollen und eine weitere Rolle ssu-root für den Standard-Mandanten angelegt. Die Rolle ssu-root ist zur Systemadministration vorgesehen.
Die Änderung der Rollenzuweisung am Server ist notwendig, da die Mandantenzugehörigkeit eines Benutzers im mandantenfähigen Betrieb über die Rollen abgebildet wird. Das bedeutet, dass ein Benutzer im Auslieferungszustand des Mandantenmodus die folgenden Rollen benötigt:
<!-- file conf/tomcat-users.xml -->
<tomcat-users>
<role rolename="ssu"/>
<role rolename="ssu_ssu-user"/>
<user username="john" password="password" roles="ssu, ssu_ssu-user"/>
</tomcat-users>
Erklärung:
Die Rolle ssu steht für die Mandanten-Identifikation des Standard-Mandanten und bestimmt, dass dieser Benutzer diesem Mandanten zugewiesen ist. Zusätzlich müssen alle Rollen des Mandanten mit dessen Mandanten-Identifikation vorangestellt werden. ([tenantIdent]_[roleIdent])
Wenn ein OIDC-Provider für das System verwendet wird, muss die Mandanten-Identifikation nicht als Rolle gesetzt sein und die Rollennamen dürfen keinen Präfix enthalten.
Mandant anlegen
Nur Benutzer, die einem bekannten Mandanten zugeordnet werden können, sind in der Lage die Anwendung zu verwenden. Dazu muss im Vorfeld ein Mandant im System über die REST-API angelegt werden. Zum Anlegen von Mandanten wird das Recht ssu.server.tenants benötig. Die Rolle ssu-root hat dieses Recht. Ein Mandant benötigt einen Anzeigenamen (displayName) und eine Identifikation (tenantIdent), die Systemweit eindeutig sein muss.
Des Weiteren müssen Rollen für den jeweiligen Mandanten angelegt werden, die den Benutzern des Mandanten zugewiesen werden. Eine Rolle besteht hier aus einer mandantenweit eindeutigen Rollen-Identifikation (roleIdent) sowie einer Liste zugehöriger Rechte. Damit sich ein Benutzer mit dieser Rolle an der Anwendung anmelden kann, benötigt er das Recht ssu.login.
Verwaltung von Mandanten
Die Verwaltung der Mandanten erfolgt ausschließlich über die REST-API. Dazu dient die Ressource Tenants. Über diese Ressource werden:
Benutzer von Mandanten und ihre Berechtigungen
Unabhängig davon, ob das System mandantenfähig betrieben wird oder nicht, befindet sich die Benutzerverwaltung immer in einem separaten System. (Tomcat, LDAP, OIDC)
Innerhalb der Anwendung wird lediglich festgelegt, welche Rollen welche Berechtigungen haben. Die externe Benutzerverwaltung legt fest, welche Benutzer welche Rollen haben und somit auch, welche Rechte sie haben und welchem Mandanten sie zugehörig sind.
Jeder Benutzer hat eine Benutzer-Identifikation (userIdent), die systemweit einmalig sein muss. Die Benutzerdaten werden bei der Anmeldung an der Anwendung (Pool-Anwendung oder REST-API) automatisch vom System angelegt. Bis dahin sind diese Benutzer dem System unbekannt und können nicht abgefragt werden. Sofern für die Integration erforderlich, können Dummy-Accounts angelegt werden, um Benutzerzugänge vor der ersten Anmeldung des Benutzers vorzubereiten. Diese bestehen nur aus dem userIdent und können verwendet werden, um administrative Vorbereitungen an dem Account vorzunehmen.
Nach der ersten Anmeldung des Benutzers sind dem System dessen Berechtigungen und dessen Mandantenzugehörigkeit bekannt. Ein Benutzer kann immer nur einem Mandanten zugeordnet sein. Ein nachträglicher Wechsel zu einem anderen Mandanten erfordert das Zurücksetzen des Benutzers. Danach kann der Benutzer einem anderen Mandanten zugeordnet werden.
Das Zurücksetzen eines Benutzers löscht alle Daten dieses Benutzers.
Benutzereinstellungen als Mandant vorgeben
Die Benutzereinstellungen werden in der Anwendung hierarchisch angewendet und überschreiben sich nacheinander, beginnend mit den vom Server vorgegebenen Einstellungen. Diese lassen sich wiederum durch die Mandanteneinstellungen überschreiben. Letztere lassen sich schließlich noch einmal durch die Benutzereinstellungen überschreiben.