Integration von grommunio in bestehende SSO-Umgebungen
1. Einleitung
Mit grommunio-auth wird die Plattform um eine Authentifizierungsschicht erweitert, die auf Keycloak basiert und moderne Standards wie OpenID Connect unterstützt. Damit ist grommunio grundsätzlich in der Lage, selbst als Identity Provider zu fungieren. In der Praxis ist dieser Ansatz jedoch selten sinnvoll.
In produktiven Umgebungen sollte Authentifizierung nicht an einzelne Anwendungen gebunden sein. Benutzer, Passwörter, Multi-Faktor-Authentifizierung und Sicherheitsrichtlinien gehören in eine zentrale Instanz. Genau hier setzt die Integration in eine bestehende SSO-Umgebung an. Statt Identitäten mehrfach zu pflegen, wird grommunio an einen vorhandenen Identity Provider angebunden und nutzt diesen für die gesamte Authentifizierung.
Dieser Ansatz reduziert nicht nur den administrativen Aufwand, sondern sorgt auch für konsistente Sicherheitsmechanismen über alle Systeme hinweg.
2. Zielarchitektur
Die Integration basiert auf einem klassischen Identity-Broker-Modell. Der in grommunio integrierte Keycloak übernimmt dabei nicht mehr die Rolle des führenden Identity Providers, sondern fungiert als Vermittler.
Authentifizierungsanfragen werden von grommunio-auth an den zentralen Identity Provider weitergeleitet. Dort erfolgt die eigentliche Anmeldung inklusive Passwortprüfung und optionaler Multi-Faktor-Authentifizierung. Nach erfolgreichem Login wird der Benutzer wieder an grommunio zurückgegeben und erhält Zugriff auf die Anwendung.
Diese Architektur hat den Vorteil, dass sämtliche sicherheitsrelevanten Prozesse zentral gesteuert werden können, während grommunio ausschließlich als Service Provider agiert.
3. Best Practice: Anbindung an einen bestehenden Identity Provider
Auch wenn es technisch möglich ist, grommunio-auth eigenständig zu betreiben, empfiehlt sich dieser Ansatz in den wenigsten Fällen. Eine isolierte Authentifizierung führt zwangsläufig zu doppelter Benutzerpflege, separaten Passwort-Richtlinien und einer zusätzlichen Verwaltung von 2FA-Mechanismen.
Gerade in Umgebungen mit mehreren Diensten entsteht dadurch schnell eine fragmentierte Identity-Landschaft. Änderungen an Benutzerkonten müssen mehrfach durchgeführt werden, Sicherheitsrichtlinien sind nicht einheitlich und das Risiko von Inkonsistenzen steigt.
Best Practice ist daher klar: grommunio wird an einen bestehenden Identity Provider angebunden und nutzt diesen als zentrale Instanz für Authentifizierung und Autorisierung. In vielen Umgebungen ist dies bereits ein vorhandener Keycloak, kann aber ebenso ein anderer OIDC-kompatibler Anbieter sein.
4. Installation von grommunio-auth
Die Installation von grommunio-auth ist auf der Appliance durch das Kommando in der cli möglich:
zypper install grommunio-auth
Nachdem das Paket installiert ist kann man grommunio-auth Konfiguration beginnen:
/usr/share/grommunio-auth/setup-grommunio-auth.sh
Die Installation ist wie schon die Installation der Appliance straight forward. Der grommunio-auth verwendet die lokale MariaDB Instanz der Appliance, sofern nicht anders definiert.
Die Konfiguration des Full Qualified Domain Names (FQDN) im nächsten Schritt ist essenziell. Hier sollte der Name unter dem auch das Webmail erreichbar ist eingetragen sein. z.B. webmail.forgeone.eu, damit wird unter https://webmail.forgeone.eu/auth/ der grommunio-auth erreichbar. Hier lohnt es sich nicht den Hostnamen zu nehmen aufgrund des Aufrufes von extern, dort ist der eigentliche Servername meistens nicht bekannt.
Im nächsten Schritt kann ein Passwort gesetzt werden. Das ist für den master REALM im grommunio-auth. Wenn nicht gesetzt, bekommt man am Ende der Installation das Passwort angezeigt.
Da der Master REALM nicht von überall erreichbar sein soll kann man das mittels IP Subnetzangaben einschränken. Diese kann man im Nachhinein jederzet unter /etc/grommunio-common/nginx/auth_allow.conf editieren.
Sollte alles bis an dieser Stelle ohne Probleme funktioniert haben, seht ihr den Login wenn man grommunio webmail aufruft mittels https://webmail.forgeone.eu/web , man wird direkt zum auth weitergerleitet.
Bei kleinen Umgebungen ist die Installation hier abgeschlossen. grommunio-auth greift dann auf die User in der grommunio Datenbank zu die im Admin Interface von grommunio hinterlegt oder mit LDAP synchronisiert wurden. Die nächsten Schritte sind für die direkte Integration in einen bestehenden IDP Provider wie einem weiteren, zentralen Keycloak, auf dem User bereits Multifaktor Authentifizierung wie TOTP und Passkey konfiguriert haben.
Sollte irgendwo ein Tippfehler passiert sein, so kann man die grommunio-auth Konfiguration unter /etc/grommunio-keycloak/ anpassen.
Die folgenden Dateien findet man in dem Ordner:
/etc/grommunio-keycloak/keycloak.conf
# SPDX-License-Identifier: AGPL-3.0-or-later# SPDX-FileCopyrightText: 2023 grommunio GmbHdb=mariadbproxy=edgehttp-port=9080http-relative-path=/authhttp-host=localhosthttp-enabled=truedb-username=grommunio_keycloakdb-password=k7OOsadisandsaIUHAISISdb-url-database=grommunio_keycloakdb-url-host=localhosthostname=webmail.forgeone.euhostname-strict=falsehostname-strict-https=falseproxy-headers=xforwarded
/etc/grommunio-keycloak/grommunio.properties
# SPDX-License-Identifier: AGPL-3.0-or-later# SPDX-FileCopyrightText: 2023 grommunio GmbHgrommunio.db-kind=org.mariadb.jdbc.Drivergrommunio.jdbc-url=jdbc:mariadb://localhost:3306/grommuniogrommunio.username=groauthgrommunio.password=Asjhdshdsya7GAGDSsytgasans
Ebenso beim Hostnamen unter /etc/gromox/keycloak.json:
{"realm" : "grommunio","auth-server-url" : "https://webmail.forgeone.eu/auth/","ssl-required" : "external","resource" : "grommunio","verify-token-audience" : true,"credentials" : {"secret" : "sdsajdinsdiNAUSsasayna63424"},"confidential-port" : 0,"policy-enforcer" : {"credentials" : { }}}
Danach einmal den grommunio-auth durchstarten:
systemctl restart grommunio-keycloak
5. Konfiguration im zentralen Identity Provider
Für die Integration wird im zentralen Identity Provider ein neuer Client für grommunio angelegt. Dieser Client stellt die Vertrauensbeziehung zwischen beiden Systemen her.
Entscheidend ist hierbei die korrekte Definition der Redirect URI. Diese gibt an, wohin der Identity Provider den Benutzer nach erfolgreicher Authentifizierung zurückleiten darf. Sie muss exakt dem Broker-Endpunkt des grommunio-Keycloaks entsprechen.
Ein typisches Beispiel sieht wie folgt aus:
https://webmail.example.com/auth/realms/grommunio/broker/<alias>/endpoint
Bereits kleine Abweichungen führen hier zu Fehlern, weshalb dieser Punkt besonders sorgfältig umgesetzt werden sollte. Nach der Erstellung des Clients wird zusätzlich ein Secret generiert, das später im grommunio-Keycloak hinterlegt wird.
6. Einrichtung des Identity Providers im grommunio-Keycloak
Auf der grommunio-Seite wird anschließend ein neuer Identity Provider konfiguriert. Dieser verweist auf den zentralen Keycloak und nutzt dessen OpenID-Connect-Discovery-Mechanismus, um die notwendigen Endpunkte automatisch zu übernehmen.
Neben Client-ID und Secret ist vor allem die Wahl des Alias relevant. Dieser wird intern für den Broker verwendet und muss konsistent in allen weiteren Konfigurationen verwendet werden.
In der Praxis haben sich Einstellungen wie ein erzwungener Synchronisationsmodus sowie das Vertrauen in die vom Identity Provider gelieferten E-Mail-Adressen bewährt. Dadurch wird sichergestellt, dass Benutzerattribute bei jedem Login aktualisiert werden und keine unnötigen Rückfragen im Login-Prozess entstehen.
7. Erzwingen von SSO und Entfernen des lokalen Logins
Nach der erfolgreichen Anbindung ist der nächste Schritt, den lokalen Login vollständig zu deaktivieren. Standardmäßig erlaubt Keycloak weiterhin die Anmeldung über lokale Benutzerkonten, was in einem SSO-Szenario nicht gewünscht ist.
Dies wird über den sogenannten Browser Flow gesteuert. Hier wird der Login-Prozess so angepasst, dass Anfragen unmittelbar an den konfigurierten Identity Provider weitergeleitet werden. Der zentrale Baustein ist dabei der „Identity Provider Redirector“, der als verpflichtender Schritt definiert wird.
Sobald dieser korrekt konfiguriert ist, erfolgt kein lokaler Login mehr. Stattdessen wird jeder Zugriff direkt an den zentralen Identity Provider delegiert. Für den Benutzer entsteht damit ein konsistentes Login-Verhalten über alle angebundenen Systeme hinweg.
8. Typische Fehler und Stolpersteine
In der Praxis treten bei der Integration immer wieder ähnliche Fehlerbilder auf. Häufig liegt die Ursache in einer fehlerhaften Redirect URI oder einem nicht korrekt konfigurierten Browser Flow. In solchen Fällen wird entweder kein Redirect durchgeführt oder der Login bricht mit generischen Fehlermeldungen ab.
Ein weiterer häufiger Punkt ist die Benutzerzuordnung. grommunio erwartet, dass Benutzer im Backend existieren und korrekt gemappt werden. Stimmen die Attribute aus dem Identity Provider nicht mit den lokalen Benutzerdaten überein, kann der Zugriff trotz erfolgreicher Authentifizierung scheitern.
Auch der direkte Zugriff auf Keycloak-Endpunkte führt oft zu Verwirrung, da Benutzer dann in der Account-Konsole landen, statt im Webmail-Interface. Entscheidend ist hier, dass der Einstieg immer über die eigentliche Anwendung erfolgt.
9. Fazit
Die Integration von grommunio in eine bestehende SSO-Umgebung ist kein optionales Feature, sondern der empfohlene Betriebsmodus für produktive Systeme. Sie reduziert Komplexität, vermeidet redundante Konfigurationen und sorgt für eine klare Trennung zwischen Anwendung und Identitätsverwaltung.
Wer bereits eine zentrale Identity-Lösung im Einsatz hat, sollte diese konsequent auch für grommunio nutzen. Das Ergebnis ist eine deutlich stabilere und wartungsärmere Umgebung mit einheitlichen Sicherheitsstandards.
10. Forecast
Im nächsten Beitrag geht es um ein ebenso zentrales Thema im Betrieb eines Mailservers: Spamfiltering. Dabei betrachten wir grommunio-antispam und rspamd im Detail und zeigen, wie sich Zustellbarkeit, Reputation und Filterqualität gezielt verbessern lassen.
