Externe User-Management und SSO mit Magnolia

Im Durchschnitt verwenden Unternehmen weit über 100 Anwendungen, und die Verwaltung von Benutzerkonten für diese verschiedenen Anwendungen kann für Benutzer und Administratoren gleichermaßen zu einer Herausforderung werden. Die Verwaltung von Konten und Berechtigungen in verschiedenen Systemen ist auch aus der Sicherheitsperspektive nicht ideal. Aus diesem Grund fordern viele Unternehmen Single Sign-On (SSO) für ihre gesamte IT-Landschaft.

SSO ist ein Authentifizierungsdienst, der es Benutzern ermöglicht, mit denselben Anmeldedaten auf mehrere Anwendungen zuzugreifen. SSO für Magnolia einzurichten bedeutet, einen zentralisierten Benutzerpool zu integrieren, der von der Authentifizierungslösung verwaltet wird. Dies ist besonders wichtig für Magnolia-Autoreninstanzen, da hier Inhalte und Erlebnisse erstellt und verwaltet werden.

Sie können SSO auch nutzen, um bestehenden Benutzerpools den Zugriff auf Ressourcen wie Ihre Website zu ermöglichen, z. B. durch die Verwendung von Social Logins von Anbietern sozialer Netzwerke wie Facebook, Twitter und Google.

Beachten Sie die folgenden Vorteile der Verwendung von Single Sign-On mit Magnolia:

Magnolias LDAP- und CAS-Module können als Vorläufer von SSO betrachtet werden. Während sie in traditionellen Unternehmensumgebungen und On-Premises-Installationen immer noch gültige Optionen sind, entsteht die Nachfrage nach einer anderen Art von Lösung, da sich die heutige Technologie zu flexiblen und transparenten Cloud-Diensten verlagert.

In diesem Artikel werden die SSO- und erweiterten Authentifizierungsfunktionen in Magnolia erläutert und die Möglichkeiten zur Integration externer Benutzerpools untersucht.

Die Sicherheit von Magnolia basiert auf JAAS, was für Java Authentication and Authorization Service steht. Der folgende Text ist ein Auszug aus der Magnolia-Dokumentation:

JAAS bietet einen standardisierten Weg für:

Sie können die Verwendung von JAAS in der Konfiguration eines Magnolia-Webanwendungs-Bundles anpassen, indem Sie die Datei .../WEB-INF/jaas.config bearbeiten. Sie ermöglicht es Ihnen, gleichzeitige Anmeldetypen für eine Magnolia-Instanz zu definieren, zum Beispiel LDAP, Azure AD und lokale Benutzerkonten.

Magnolia prüft, ob ein Benutzer die erforderlichen Berechtigungen hat, bevor es den Zugriff auf Ressourcen wie Webseiten, Dokumente, Vorlagen oder andere Datentypen gewährt.

Weitere Informationen finden Sie in der Magnolia-Sicherheitsdokumentation und in der Konfiguration von JAAS-basierten Logins.

Zu den Sicherheitsobjekten und -komponenten in Magnolia gehören Benutzer, Gruppen, Rollen und Login-Module. Alle oben genannten sind von einer gemeinsamen Codebasis abgeleitet, aber Sie können sie durch andere Login-Module ersetzen oder ihre Konfiguration ändern.

Neue Login-Module können die zentrale Sicherheitsarchitektur von Magnolia nutzen und bieten gleichzeitig zusätzliche Möglichkeiten zur Integration externer Authentifizierungsanbieter.

Dieser elegante Ansatz ermöglicht es, die externe Benutzerverwaltung zu aktivieren, ohne den Kerncode von Magnolia zu verändern. Dabei besteht weder die Gefahr, dass die Kompatibilität mit zukünftigen Magnolia-Releases unterbrochen wird, noch ist die Pflege einer eigenen Codebasis erforderlich.

Magnolia bietet verschiedene Module für die Benutzerauthentifizierung über ein Drittsystem.

Das Modul LDAP Connector ermöglicht die Authentifizierung gegenüber einem LDAP-Server. Es wird in Unternehmensumgebungen eingesetzt, in denen LDAP-Authentifizierung der Standard ist. Dazu gehören Umgebungen, die sich auf den beliebten Verzeichnisdienst Active Directory (AD) von Microsoft stützen.

CAS ist eine Open-Source-Java-Serverkomponente der Apereo Foundation. Sie bietet eine Single-Sign-On-Lösung (SSO) für das Web. Neben der Implementierung des CAS-Protokolls unterstützt sie auch die Protokolle SAML, OAuth und OpenID. Darüber hinaus integriert sie transparent andere Authentifizierungsdienste.

Das CAS-Modul von Magnolia setzt das Modul LDAP Connector voraus. Bei der Implementierung einer CAS-Lösung sollten vertiefte Kenntnisse über Java-Server und deren Betrieb vorhanden sein.

Magnolia bietet ein flexibles SSO-Modul, das auf den Protokollen OAuth und OpenID Connect (OICD) und ihren jeweiligen Authentifizierungsabläufen basiert. Die Einrichtung umfasst die Registrierung von Magnolia als Client und die Angabe von Konfigurationsdetails wie Client-ID und Geheimnis sowie die Callback-URL.

Im Gegensatz zu den oben genannten Modulen LDAP Connector und CAS verwendet das Magnolia SSO-Modul die Protokolle OAuth und OpenID Connect (OIDC).

Bei der Integration von Magnolia mit einer externen Authentifizierungslösung sind nur die Protokolle relevant. Beide Systeme müssen in der Lage sein, in einer gemeinsamen Sprache, d.h. dem Protokoll, zu kommunizieren. In der Vergangenheit wurde fälschlicherweise angenommen, dass bestimmte Keycloak-Bibliotheken mit Magnolia SSO verwendet werden müssen. Dies ist aber nicht der Fall: Magnolia SSO ist nicht an ein bestimmtes Produkt oder eine bestimmte Bibliothek gebunden. Es kann jede Benutzerauthentifizierung nutzen, die dem Standard des OAuth/OIDC-Protokolls entspricht. Für einige Anwendungsfälle - wie das Parsen von Gruppen-/Rolleninformationen oder die Wiederverwendung von Token - kann es jedoch notwendig sein, den Code des SSO-Moduls anzupassen.

Zum besseren Verständnis erläutern wir hier die unterstützten Protokolle.

OAuth 2.0

Laut der Internet Engineering Task Force (IETF ) "ermöglicht das OAuth 2.0 Autorisierungs-Framework einer Drittanbieter-Anwendung, begrenzten Zugang zu einem HTTP-Dienst zu erhalten, entweder im Namen eines Ressourcenbesitzers, indem eine Genehmigungsinteraktion zwischen dem Ressourcenbesitzer und dem HTTP-Dienst orchestriert wird, oder indem der Drittanbieter-Anwendung erlaubt wird, in eigenem Namen Zugang zu erhalten".

OAuth 2.0 hat sich als Standard für die Autorisierung des API-Zugriffs im Web etabliert, weil es einfach und sicher ist und viele Arten von Anwendungen unterstützt - von Portalen bis hin zu Anwendungen, die auf verschiedenen Geräten laufen.

Der Zweck von OAuth 2.0 ist die Autorisierung: die Gewährung des Zugangs von einer Anwendung zu einer anderen, um Daten oder Funktionen zu nutzen, ohne sich mit der ursprünglichen Authentifizierung befassen zu müssen. OAuth 2.0 ist kein Authentifizierungsprotokoll; es liefert keine Benutzerkennung oder erweiterte Informationen über einen Benutzer. Die meisten Anbieter sozialer Netzwerke, die Anmeldedienste anbieten, um sich bei Anwendungen von Drittanbietern anzumelden - wie Gmail, Facebook und Twitter - verwenden die OAuth-Protokolle.

OpenID Connect (OIDC)

Leider wird der Zweck von OpenID Connect (OIDC) oft missverstanden, weil es mit dem früheren OpenID-Standard verwechselt wird, der ein dezentrales Authentifizierungsprotokoll bietet. OpenID ist nicht mit OAuth verwandt und wird von Magnolia nicht unterstützt.

OpenID Connect hingegen ist eine Schicht über OAuth 2.x, die es Clients ermöglicht, die Identität eines Benutzers zu überprüfen. Sie fügt Profil- und Anmeldeinformationen über das eingeloggte Benutzerkonto hinzu.

Kurz gesagt, OIDC ermöglicht die Verwendung von Logins über mehrere Anwendungen hinweg, was der Zweck von SSO ist. Magnolia empfiehlt die Verwendung von OIDC anstelle von OAuth 2.0, wann immer dies möglich ist, insbesondere bei der Aktivierung des Zugriffs auf Magnolia AdminCentral. Die meisten Authentifizierungslösungen für Unternehmen unterstützen OIDC zusätzlich zu anderen Protokollen.

Lösungen, die OIDC unterstützen, werden oft als Identitätsanbieter bezeichnet, da sie Informationen über die Identität des Benutzers bereitstellen. Beispiele für Identitätsanbieter sind Azure Active Directory (Azure AD), Auth0, AWS Cognito, Keycloak und Okta.

SAML ist ein sicheres und robustes Protokoll, das von einigen Authentifizierungsservern unterstützt wird. Der Nachteil ist, dass SAML veraltet ist und den Anforderungen moderner Anwendungen nicht gerecht wird. Außerdem sind die zugrunde liegenden Standards für XML-Signaturen komplex, und die Verwaltung von X.509-Zertifikaten in Produktionsumgebungen ist umständlich.

Magnolia hat daher beschlossen, die Entwicklung auf die modernen Protokolle OAuth 2.0 und OpenID Connect zu konzentrieren. Folglich bedeutet dies, dass wir SAML nicht direkt unterstützen.

Um SSO für Magnolia einzurichten, muss es als Client für den Autorisierungsdienst konfiguriert werden.

Um Magnolia als gültigen Client zu identifizieren, erhält Magnolia eine Client-ID und ein Client-Geheimnis, manchmal auch App-ID und App-Geheimnis genannt.

Außerdem müssen Sie eine oder mehrere Callback-URLs definieren, die auch als Redirect-URIs bezeichnet werden. Diese URLs werden vom Authentifizierungssystem verwendet, um Magnolia nach einer erfolgreichen Anmeldung "zurückzurufen".

Der OAuth 2.0-Standard unterstützt mehrere Arten von "Flows"; der gebräuchlichste ist der "Autorisierungscode-Flow", der von Magnolia SSO-Modulen verwendet wird. Die Abläufe für OIDC und OAuth 2.0 sind fast identisch. Der OIDC-Flow schließt den OpenID-Bereich in die erste Anfrage ein und gibt ein ID-Token zusätzlich zum OAuth 2.0-Zugriffstoken aus.

Magnolia vergibt dann die Berechtigungen für externe Benutzer auf der Grundlage der Rollen des Benutzers. Magnolia speichert einen externen Benutzer nicht. Er existiert nur im Speicher, bis sich ein Benutzer abmeldet oder die Sitzung abläuft.

1. Ein Benutzer möchte Magnolia erlauben, Informationen wie Benutzername, Sprache, Gruppen- und Rollenmitgliedschaft von einem Autorisierungsserver abzurufen, damit Magnolia die Berechtigungen des Benutzers für den Zugriff auf Ressourcen wie AdminCentral oder eine geschützte Website zusammenstellen kann.

2. Magnolia leitet den Browser des Benutzers an den Autorisierungsserver weiter. Die Umleitung enthält die folgenden Parameter: Client-ID, Callback-URL, Antworttyp und die Bereiche, einschließlich OpenID.

3. Wenn sich der Benutzer nicht vorher angemeldet hat, findet der Autorisierungsserver keine aktive Sitzung für den Benutzer. Er fordert zur Anmeldung auf und prüft die Identität des Benutzers. Falls konfiguriert, nutzt dieser Prozess die Multi-Faktor-Authentifizierung.

4. Je nach den von Magnolia angeforderten Bereichen fragt der Server nach der Zustimmung des Nutzers.

5. Der Autorisierungsserver leitet dann unter Verwendung der Callback-URL und des Autorisierungscodes an Magnolia weiter.

6. Wenn Magnolia den Autorisierungscode über die Callback-URL erhält, kontaktiert das Backend den Autorisierungsserver über eine sichere Verbindung. Es überträgt den Autorisierungscode, die Client-ID und das Client-Geheimnis.

7. Der Autorisierungsserver prüft die Informationen und antwortet, wenn sie korrekt sind, mit einem Zugangs-Token und einem ID-Token über die sichere Verbindung.

8. Sobald Magnolia die Token erhalten hat, kann es das Zugriffstoken als Schlüssel verwenden, um Benutzerinformationen vom Ressourcenserver abzufragen. Je nach Konfiguration des Autorisierungsservers können die Informationen bereits im ID-Token enthalten sein (siehe unten für Token-Typen).

9. Magnolia erstellt ein Benutzerobjekt basierend auf dem erhaltenen Benutzernamen und der ID. Zusätzliche Attribute wie E-Mail und Sprache des Benutzers werden zugewiesen, falls vorhanden.

Wenn der Autorisierungsserver Rollen und Gruppen bereitstellt, gleicht Magnolia deren Namen mit den lokalen Rollen und Gruppen in seinem Backend ab. Existiert eine Rolle oder Gruppe nicht in Magnolia, wird sie ignoriert. Wenn der Autorisierungsserver keine Rollen und Gruppen bereitstellt, wendet Magnolia Standardrollen und -gruppen aus der SSO-Konfiguration auf das Benutzerobjekt an.

Magnolia verwendet ein Zugriffstoken als Schlüssel für die Abfrage der Daten eines Benutzers auf dem Ressourcenserver. Der Ressourcenserver überprüft das Token, um festzustellen, ob Magnolia auf die angeforderte Ressource zugreifen darf. Während das Token ein wichtiger Teil des Datenflusses ist, ist sein Inhalt für Magnolia irrelevant. OAuth 2.0 und OpenID Connect verwenden Zugriffstoken in ihrem Ablauf.

Der OIDC-Fluss verwendet ebenfalls ein ID-Token. Seine Nutzlast hat das Format eines JSON-Web-Tokens (JWT) und der Inhalt der Nutzlast wird als Claims bezeichnet. Magnolia parst die Claims mithilfe eines Decoders.

Zusätzlich zu den grundlegenden Benutzerinformationen enthält ein ID-Token oft auch Informationen wie ein Ablaufdatum und den Aussteller des Tokens. Darüber hinaus kann der Authentifizierungsserver Informationen wie die Rollen des Benutzers in die Nutzdaten aufnehmen, um den Datenaustausch effizienter zu gestalten.

Magnolia kann mit Hilfe des Zugriffstokens zusätzliche Informationen vom Ressourcenserver anfordern.

Beim Testen oder Debuggen können Sie den Inhalt eines ID-Tokens mit Diensten wie https://jwt.io/ oder https://jwt.ms/ untersuchen .

Der OpenID-Connect-Standard bietet eine Fülle von Funktionen für die Verwendung mit Magnolia. Die SSO-Module können diese Funktionen nutzen, wenn die Authentifizierungslösung sie unterstützt.

Multi-Faktor-Authentifizierung

SSO lagert die Benutzerauthentifizierung an einen Authentifizierungsserver aus. Sie ist daher für Magnolia transparent. Wenn der Authentifizierungsserver die Multi-Faktor-Authentifizierung unterstützt, kann Magnolia davon profitieren.

Bei der Anmeldung in Magnolia wird ein Benutzer zum Authentifizierungsserver umgeleitet und kehrt erst nach erfolgreicher Anmeldung zu Magnolia zurück. Der Authentifizierungsprozess und die damit verbundenen Schritte sind für Magnolia irrelevant, selbst wenn das Senden von Rauchzeichen als Teil der Authentifizierung erforderlich wäre.

Dies gilt auch für Anmeldungen über Ihre Konten in sozialen Netzwerken. Wenn Sie in den Einstellungen Ihres Google-Kontos die Zwei-Faktor-Authentifizierung (2FA) aktiviert haben, müssen Sie bei allen Diensten, die Google Sign-In verwenden, die 2FA durchführen - es sei denn, Sie haben bereits eine bestehende Sitzung mit dem Anbieter.

Nahtlose Geräteintegration

Viele Nutzer haben mehr Geräte als nur einen Desktop oder Laptop. Sie möchten zwischen den Geräten wechseln, ohne die Anmeldedaten immer wieder neu eingeben zu müssen. Authentifizierungslösungen können Geräte anhand ihrer Hardware-ID identifizieren und sie bekannten Benutzern in einer Organisation zuordnen. Wenn sich ein Benutzer bereits bei einem Desktop-Computer angemeldet hat, kann der Authentifizierungsserver eine Anfrage von einem registrierten Gerät als von demselben Benutzer stammend erkennen und den Zugriff ohne erneute Anmeldung gewähren.

Integrationsdrehscheibe

Magnolia-Module unterstützen LDAP, CAS, OAuth und OpenID Connect. Sie können jede Autorisierungslösung, die eines der Protokolle beherrscht, als transparenten "Integrations-Hub" verwenden, um verschiedene Arten von Benutzerpools zu verwalten. Durch Integrations-Hubs entfällt die Notwendigkeit, verschiedene Authentifizierungsprotokolle zu implementieren.

Keycloak kann zum Beispiel viele Arten von Benutzerdatenbanken integrieren, einschließlich LDAP, SAML und Social Logins, so dass Magnolia Benutzer aus ihrem Benutzerpool abrufen kann.

Eine typische Magnolia-Installation besteht aus einer Autoreninstanz und mindestens zwei öffentlichen Instanzen. Technisch gesehen können wir zwischen Backend- (Autor) und Frontend-Zugang (öffentlich) unterscheiden. Für beide Arten von Magnolia-Instanzen ist es sinnvoll, externe Nutzer zu aktivieren, auch wenn die Anwendungsfälle unterschiedlich sind.

Stellen Sie sich einen Bereich einer Website vor, der vor anonymen Zugriffen geschützt ist und eine Anmeldung erfordert, z. B. ein Mitglieder- oder Kundenportal. Dies ist eine häufige Anforderung, die durch das Modul Public User Registration (PUR) abgedeckt wird. Das Modul ermöglicht auch die Registrierung und Verwaltung von Konten. PUR-Logins werden in der Magnolia-Datenbank gespeichert und können von Diensten außerhalb von Magnolia nicht wiederverwendet werden.

Viele Websites und Portale bieten die Authentifizierung über soziale Netzwerke als Option an, um die Zugangshürde zu senken. Durch die Verwendung des Magnolia SSO-Moduls können Sie die gängigsten sozialen Netzwerke ganz einfach per Konfiguration integrieren. Bei der Arbeit mit sozialen Logins ist zu beachten, dass diese in der Regel keine erweiterten Benutzerinformationen wie Gruppen- oder Rollenzugehörigkeit bereitstellen.

Wenn Sie den Zugriff auf einen Bereich Ihrer Website beschränken, ist dies in der Regel kein Problem, da er für einen vordefinierten Anwendungsfall verwendet wird. Sie können Standardrollen und -gruppen für Benutzer definieren, die sich erfolgreich über eine soziale Anmeldung authentifizieren.

Der Nachteil dieses Ansatzes ist, dass Magnolia nicht zwischen verschiedenen Arten von Benutzern unterscheiden kann. Verschiedene Rollen und Gruppen zu haben, erfordert eine ausgefeiltere Authentifizierungslösung wie Azure AD oder Keycloak.

Wenn Sie SSO für die Benutzer einer Magnolia-Autoreninstanz aktivieren, ist es wichtig, den verschiedenen Benutzerkategorien wie Redakteuren, Herausgebern und Superusern Rollen zuzuweisen. Sie können Magnolias LDAP-Connector und CAS-Module zur Integration mit Authentifizierungslösungen für die zentrale Benutzerverwaltung verwenden.

Das Magnolia SSO-Modul kann mit jeder Authentifizierungslösung integriert werden, die dem OpenID Connect-Protokollstandard und dem entsprechenden Autorisierungscodefluss entspricht. Sie können diese Dienste nutzen, um Gruppen- und Rolleninformationen abzurufen, indem Sie die vom Authentifizierungsserver bereitgestellten Daten parsen.

Es macht keinen Sinn, den Zugriff auf Magnolia-Autoreninstanzen mit Social Logins zu verwalten, da diese keine Rollen und Gruppen anbieten.

Vor einigen Jahren entwickelte Magnolia Professional Services Code, um OAuth-Logins für die Website eines Kunden zu ermöglichen. Daraufhin haben wir ein Modul entwickelt, das OAuth-basierte Anmeldungen ermöglicht - das oben beschriebene SSO-Modul.

Wir stellten es Kunden über unseren Inkubator zur Verfügung und erweiterten das Modul später um die Unterstützung des OpenID Connect-Protokolls. Das Modul hat sich als sehr erfolgreich erwiesen und wird in vielen Unternehmensprojekten zur Implementierung verschiedener Authentifizierungsdienste eingesetzt.

Aufgrund der hohen Nachfrage hat Magnolia mit der Entwicklung eines neuen SSO-Moduls begonnen, das eine leistungsfähigere Bibliothek, PAC4J, verwendet. Das neue Modul unterstützt das OpenID Connect-Protokoll und eignet sich gut für moderne Cloud-Umgebungen.

Die Basisimplementierung ist fertig und wir sind dabei, erweiterte Anwendungsfälle zu testen. In der Zwischenzeit können Sie unsere SSO-, LDAP Connector- und CAS-Module verwenden. Wenn Sie an zusätzlichen Funktionen interessiert sind, halten Sie Ausschau nach weiteren Artikeln über das neue SSO-Modul, sobald dessen Entwicklung fortgeschritten ist.