Einstieg in die Benutzer- und Rechteverwaltung
Hier finden Sie Informationen zur Verwaltung von Benutzern und Zugriffsrechten in FirstSpirit Cloud. Die Information richtet sich primär an Projekt-Admins sowie an Benutzer mit der Rolle User-Manager, die für die Einrichtung und Pflege von Benutzerkonten, Gruppen und Zugriffsrechten in der FirstSpirit Cloud-Umgebung verantwortlich sind.
Das Dokument erläutert die zugrunde liegenden Konzepte sowie die Benutzerverwaltung in Keycloak und führt Sie durch zwei Betriebsmodelle:
Authentifizierung in FirstSpirit Cloud
Für die Benutzer- und Rechteverwaltung setzt FirstSpirit Cloud die Open-Source-Software Keycloak ein. Keycloak ist eine Single-Sign-On-Lösung (SSO) für Webanwendungen und RESTful-Webdienste.
Intern arbeitet Keycloak als Identity Provider (IdP) für FirstSpirit-Anwendungen mit dem FirstSpirit-Server als Client. So ist sichergestellt, dass die Benutzerkonten vollständig von den Anwendungen isoliert sind und die Anwendungen niemals die Anmeldedaten eines Benutzers einsehen können.

So funktioniert der Login
Wenn sich ein Benutzer bei der FirstSpirit Cloud anmeldet, wird seine Login-Anfrage an den Keycloak-Server geleitet und dort authentifiziert. Nach einem erfolgreichen Login sendet der Keycloak-Server einen Identity-Token an den FirstSpirit-Server, in dem alle erforderlichen Informationen enthalten sind (UserID, Gruppe, Gültigkeitsdauer). Somit hat der Benutzer Zugriff auf Bereiche, die für ihn freigegeben wurden.
Alle Informationen über die Berechtigungen des Benutzers sind in dem Identity-Token enthalten. Der Benutzer kann deshalb jede weitere Anwendung, für die er Zugriffsrechte hat, ohne manuelle Authentifizierung nutzen. Dieses Verfahren wird als Single Sign-On (SSO) bezeichnet.
So unterscheiden sich die Betriebsmodelle: mit und ohne IdP
In FirstSpirit Cloud stehen Ihnen zwei Modelle für die Benutzerverwaltung zur Verfügung. Welches Modell für Ihre Organisation geeignet ist, hängt davon ab, ob Sie einen unternehmenseigenen Identity Provider (IdP) anbinden möchten. FirstSpirit empfiehlt die Verwendung eines externen IdP.
Mit externem Identity Provider
Sie binden einen unternehmenseigenen IdP über OIDC oder SAML an FirstSpirit Cloud an. Benutzer melden sich über Ihre bestehende Unternehmensanmeldung an. Beim ersten Login wird automatisch ein Keycloak-Konto erstellt. Die Zuweisung von Gruppen und Berechtigungen nehmen Sie als User-Manager weiterhin manuell in Keycloak vor.
Ohne externen Identity Provider
Benutzer werden direkt in Keycloak angelegt und verwaltet. Anmeldedaten werden ausschließlich in Keycloak gespeichert. Dieses Modell erfordert keine zusätzliche Infrastruktur. Als Benutzer mit der Rolle User-Manager verwalten Sie Benutzerkonten und Gruppen vollständig in Keycloak.
Modelle im Vergleich
| Ohne IdP | Mit IdP | |
|---|---|---|
| Benutzeranmeldung | Keycloak-Konto mit lokalem Passwort | Unternehmensanmeldung via IdP |
| Sicherheitsrichtlinien | Keycloak-Passwortrichtlinien | Richtlinien des Unternehmens gelten automatisch auch in der FirstSpirit Cloud |
| Kontoerstellung | User-Manager legt Konten manuell in Keycloak an | Automatische Erstellung in Keycloak beim ersten Login |
| Gruppenerstellung | Manuelle Erstellung in Keycloak | Manuelle Erstellung in Keycloak |
| Gruppenberechtigungen | Manuelle Zuweisung in Keycloak | Manuelle Zuweisung in Keycloak oder automatische Zuweisung via Group Mapping |
| Zusätzliche Infrastruktur | Nicht erforderlich | Eigener IdP erforderlich (OIDC oder SAML) |
| Geeignet für | Teams ohne SSO-Anforderung | Organisationen mit zentralem Identity Management |
Realms
Damit eine Person (z.B. Entwickler) mit FirstSpirit Cloud arbeiten kann, muss sie
- als Benutzer im Zugangsbereich des Kunden registriert sein,
- als Benutzer mindestens einer Gruppe angehören, die den Zugriff auf mindestens eine der FirstSpirit Cloud-Umgebungen erlaubt (DEV/QA/PROD) und
- einer Rechte-Gruppe (z.B. Redakteur) zugewiesen sein.
Diese Bedingungen werden in einem als "Realm" bezeichneten Datenbereich durch entsprechende Konfigurationen erfüllt. Die Rechte werden dabei innerhalb von FirstSpirit konfiguriert.
Realms sind zentrale Organisationsmittel für die Verwaltung von Rechten. Ein Realm ist eine Konfigurationseinheit, in der Datensätze von
- Benutzern
- Gruppen
- Zuordnungen zwischen Benutzern und Gruppen
Federations
Wie jeder Kunde erhält auch jedes Partnerunternehmen genau einen Realm, wenn es FirstSpirit Cloud-Kunden bei der Umsetzung von Projekten unterstützt.
Damit ein Partnerunternehmen auf die Kundenumgebung zugreifen kann, wird sein Realm mit dem Realm des Kunden verbunden. Dieser Mechanismus wird als Federation bezeichnet und durch FirstSpirit auf Antrag des Kunden eingerichtet. Nach der Einrichtung sind die Benutzer des Partnerunternehmens im Realm des Kunden verfügbar, ihnen sind aber noch keine Rechte zugewiesen. Benutzer-Rechte innerhalb des Kunden-Realms werden durch den Kunden festgelegt.
Benutzer
Benutzer sind Identitäten, die sich in Ihrem System anmelden können. In der FirstSpirit Cloud müssen zu jedem Benutzer folgende Informationen vorliegen:
- Vorname
- Nachname
- E-Mail-Adresse (gleichzeitig der FirstSpirit-Benutzername)
- Zugehörigkeit zu einer oder mehreren Gruppen
Ein Benutzer erhält seine Rechte ausschließlich durch die Vererbung von Rechten aus einer oder mehreren Gruppen oder Rollen. Hierfür muss der Benutzer Mitglied einer solchen Gruppe sein oder eine Rolle zugewiesen bekommen.
Gruppen
In Gruppen werden mehrere Benutzer gemeinsam verwaltet. Ein Benutzer erhält seine Rechte durch die Zuordnung zu einer oder mehreren Gruppen.
< Tenant >-git-user und < Tenant >-developers-dev).Gruppennamen sind in der Regel zusammengesetzt aus dem Tenant als Präfix und einem rechtepezifischen Suffix, getrennt durch einen Bindestrich.
Beispiel
Der Gruppenname testtenant-git-user ergibt sich aus:
- dem Tenant testtenant und
- dem rechtespezifischen Suffix git-user, das alle Benutzer mit Git-Zugriffsrechten konnotiert.
Gruppen der Standardumgebung
In der FirstSpirit Cloud sind standardmäßig drei Umgebungen enthalten:
- Dev (Development)
- QA (Quality Assurance)
- Prod (Productive).
Mehr Information dazu finden Sie auch im FirstSpirit Guide.

Die drei Umgebungen bilden eine Stufenfolge mit steigendem Qualitätsanspruch: Änderungen werden in der Entwicklungsumgebung erstellt, in der QA-Umgebung getestet und anschließend in die Produktion übertragen. Alle drei Umgebungen enthalten nahezu die gleichen Projekte. Wie die Umgebungen im Einzelnen genutzt werden und wie sich die Projekte unterscheiden, legt der Kunde fest.
Vorlagen- und Einstellungsänderungen werden regelmäßig in die nächste Umgebung verschoben, um unterschiedliche Entwicklungsstände zu vermeiden.
Während Dev und QA in der Regel Testdaten enthalten, enthält die Prod-Umgebung den gesamten Inhalt des Live-Projekts.
| Gruppe | Umgebung | Beschreibung | Beispiel-Name |
|---|---|---|---|
| <Tenant>-users-dev | Entwicklung | Isolierte Umgebung für Entwickler und Redakteure, ohne Auswirkungen auf Produktion oder andere Nutzer. | testtenant-users-dev |
| <Tenant>-users-qa | Qualitätssicherung (Staging) | Umgebung zum Testen und Abnehmen von Änderungen, bevor diese in die Produktion übertragen werden. Ziel ist ein Stand, der in die Produktionsumgebung übernommen werden kann. | testtenant-users-qa |
| <Tenant>-users-prod | Produktion | Enthält alle veröffentlichten, kundenverfügbaren Projekte. | testtenant-users-prod |
Weitere Gruppen
| Gruppe | Beschreibung |
|---|---|
| <Tenant>-chiefeditors | Redakteure mit erweiterten Berechtigungen: Direkte Freigaben, Vergabe von Redaktions- und Benutzerrechten |
| <Tenant>-developers-dev | FirstSpirit-Vorlagenentwickler: Artifactory-Zugriff |
| <Tenant>-editors | Klassische Redakteure: Einsehen aller, Bearbeiten bestimmter Inhalte. Keine Freigabe-Rechte |
| <Tenant>-git-user | Zugriff auf Bitbucket (Git) und Bamboo |
| <Tenant>-projectadmins-dev | Projekt-Administratoren für die Entwicklungs-Umgebung: Gruppenberechtigungen, Sprachen, Hintergrundprozesse |
| <Tenant>-projectadmins-qa | Projekt-Administratoren für die QA-Umgebung |
| <Tenant>-projectadmins-prod | Projekt-Administratoren für die Produktiv-Umgebung: Verwaltung öffentlich zugänglicher Websites |
| <Tenant>-template-distribution | Übertragung von Projektvorlagen von Dev → QA → Prod |
Rechte zuweisen
Zugriffsrechte werden zentral in Keycloak verwaltet sowohl für FirstSpirit als auch für andere Anwendungen die Teil des FirstSpirit-Universums sind, wie Git, Bamboo oder Artifactory.
- Rechte für FirstSpirit: Rechte für den Zugriff auf FirstSpirit werden ausschließlich über Gruppen vergeben. Dazu müssen im jeweiligen FirstSpirit-Projekt externe Gruppen konfiguriert werden, die auf Gruppen in Keycloak gemappt sind. Weitere Informationen finden Sie unter Externe Gruppen im FirstSpirit-Projekt anlegen.
- Rechte für andere Anwendungen: Für den Zugriff auf Git, Bamboo und Artifactory werden Rechte direkt in Keycloak über Gruppen vergeben.
- Rollen in Keycloak: Zugriffsrechte für FirstSpirit und andere Anwendungen werden über Gruppen vergeben. Ausnahmen sind die beiden Keycloak-Rollen
User-Managerundpassword-user. Diese Rollen sind keine FirstSpirit- oder Anwendungsrollen. Die Rollepassword-userhat jedoch einen indirekten Effekt auf den FirstSpirit-Zugang, siehe password-user-Rolle.
User-Manager-Rolle
In Keycloak existiert die Rolle User-Manager, mit der Benutzer verwaltet werden können. In einem Realm muss mindestens ein Benutzer existieren, der diese Rolle innehat, um weitere Benutzer erstellen und Rechte vergeben zu können. Mit einer Voreinstellung durch FirstSpirit erhält der erste Benutzer in Ihrer FirstSpirit Cloud diese Rolle von Anfang an.
Einer Gruppe kann diese Rolle nicht zugewiesen werden und es gibt auch keine Gruppe mit dem Recht, Benutzer zu verwalten.
User-Manager sollte nur an Personen mit einer Nutzerverwaltungs-Funktion im Unternehmen vergeben werden. Je nach Aufbau des Unternehmens kann das z.B. ein Abteilungs-, Bereichs oder Projektleiter, oder Mitarbeiter der IT-Abteilung sein.password-user-Rolle
Die Rolle password-user in Keycloak steuert, welche Benutzer sich ein lokales Passwort in Keycloak setzen und sich damit lokal authentifizieren können. Ein lokales Passwort ist unabhängig vom Passwort eines externen Identity Providers und wird für technische Anwendungsfälle benötigt, bei denen eine Browser-basierte SSO-Authentifizierung nicht möglich ist, z. B. bei FirstSpirit CLI, Aufträgen oder direkter API-Authentifizierung.
Unabhängig davon ob Sie ein IdP verwenden, erhalten alle Benutzer die Rolle password-user standardmäßig über die Default-Rollen. Wenn Sie nach der Einführung einer IdP Verbindung die Möglichkeit zur lokalen Passwort-Vergabe für Ihre Benutzer einschränken wollen, dann wenden Sie sich an den FirstSpirit Support um die Rolle aus den Default-Rollen entfernen zu lassen. Anschließend kann der User-Manager die Rolle gezielt an einzelne Benutzer oder Gruppen vergeben.
Wird einem Benutzer die Rolle password-user entzogen so kann dieser kein lokales Passwort mehr setzen oder ändern. Außerdem ist eine lokale Authentifizierung nicht mehr möglich, auch wenn bereits ein Passwort hinterlegt ist. Eine bestehende SSO-Anmeldung über den IdP ist davon nicht betroffen.
Keycloak-FirstSpirit Mapping
Auf dem Keycloak-Server erhalten Benutzer Zugriffsrechte, indem sie Gruppen zugeordnet werden. Die Verknüpfung von Zugriffsrechten und Arbeitsbereichen wird in FirstSpirit-Server-Gruppen konfiguriert.
Um Gruppen zwischen Keykloak und FirstSpirit zu verknüpfen, müssen auf dem FirstSpirit-Server dieselben Gruppennamen verwendet werden, wie auf dem Keycloak-Server.
- Die Gruppen werden in Keycloak angelegt oder sind bereits standardmäßig angelegt worden.
- In FirstSpirit werden externe Gruppen angelegt. Der Gruppenname im Feld "Externe Bezeichnung" muss identisch zum Gruppennamen in Keycloak sein.

Beispiel: Gruppennamen-Mapping:
- testtenant-editors
- testtenant-git-user
- testtenant-users-dev
- testtenant-users-qa
- testtenant-users-prod