Secure Fusion: Einmalige Anmeldung

Single Sign-On (SSO) Mechanismen ermöglichen es einem Benutzer, dieselbe ID und dasselbe Passwort zu verwenden, um Zugang zu einem oder…

Single Sign-On (SSO) Mechanismen ermöglichen es einem Benutzer, dieselbe ID und dasselbe Passwort zu verwenden, um Zugang zu einem oder mehreren verbundenen Systemen zu erhalten. In einer Umgebung mit Webdiensten oder verteilter Datenverarbeitung kann eine einmalige Anmeldung nur erreicht werden, indem Informationen über die Anmeldestelle bei allen Systemen registriert werden, die ihre Dienste benötigen. Der vorherige Artikel in dieser Serie Secure Fusion: Leveraging LDAP zeigt, wie Sie Fusion so konfigurieren, dass Passwörter und Berechtigungen von einem externen LDAP-Server verwaltet werden. Fusion kann so konfiguriert werden, dass es mit zwei weiteren Arten von Single Sign-On-Mechanismen arbeitet: Kerberos und SAML 2.0. Dieser Artikel behandelt die Konfigurationsdetails für diese beiden.

Fusion Logins und Sicherheitsbereiche

Ein Security Realm enthält Informationen über eine Domäne, einen Authentifizierungsmechanismus und die Berechtigungen, die Benutzern aus dieser Domäne zugewiesen werden. Eine Fusion-Instanz kann mehrere Security Realms verwalten, so dass Benutzer aus verschiedenen Domänen Zugriff auf bestimmte Fusion-Sammlungen erhalten können.

Bei einem nicht-nativen Sicherheitsbereich existieren die Domäne und ihre Benutzerdatenbank außerhalb von Fusion. Wenn Sie Fusion für diesen Bereich konfigurieren, wird die Verwaltung der Fusion-Benutzerkonten vereinfacht. Fusion muss nur den Benutzernamen und den Sicherheitsbereich des Benutzers speichern. Die Berechtigungen für einen bestimmten Benutzer werden von den Berechtigungen geerbt, die für die Benutzer und Gruppen definiert sind, die zu diesem Bereich gehören. Es ist zwar immer noch möglich, die Berechtigungen für diesen Benutzer direkt in Fusion zu verwalten, aber das widerspricht dem Prinzip, die Benutzerverwaltung jemand anderem zu überlassen.

Wenn Sie zum ersten Mal über den Browser auf Fusion zugreifen, enthält das Anmeldefenster drei Eingaben: Benutzername, Kennwort und ein nicht beschriftetes Pulldown-Menü für die Auswahl des Realms. Die Standardauswahl ist der native Bereich von Fusion, der immer verfügbar ist. Um sich über einen nicht-nativen Bereich anzumelden, wählen Sie den entsprechenden Bereichsnamen aus dem Pulldown-Menü. Wenn Sie einen nicht nativen Bereich auswählen, können sich die Eingaben im Anmeldefenster ändern. Bei einem LDAP-Bereich gibt ein Benutzer seinen LDAP-Benutzernamen und sein Kennwort in die entsprechenden Felder im Anmeldefenster ein und Fusion leitet diese Informationen zur Authentifizierung an den LDAP-Server für diesen Bereich weiter. Für die Anmeldung bei einem Kerberos- oder SAML-Realm gibt es im Anmeldefenster keine Eingaben für beide. Im folgenden Screenshot sehen Sie auf der linken Seite das Anmeldefenster für einen nativen oder LDAP-Realm und auf der rechten Seite das Anmeldefenster für einen SAML- oder Kerberos-Realm:

Da für die Anmeldung bei Fusion ein Benutzername und ein Passwort erforderlich sind, stellt sich die Frage, wie die Anmeldung funktioniert. Es gibt keine Magie, nur ein paar Browser-Trickser. Bei SAML- und Kerberos-Anmeldungen wird der Browser zum Vermittler zwischen Fusion und dem Authentifizierungsmechanismus. Da der Authentifizierungsprozess indirekt über den Browser abläuft, erfordert die Systemkonfiguration zusätzliche Arbeit, die über die Registrierung der Security Realm-Informationen in Fusion hinausgeht. Um die Details der Konfiguration zu verstehen, geben wir einen kurzen Überblick über die Funktionsweise von SAML und Kerberos.

SAML

SAML ist ein Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten zwischen Sicherheitsdomänen. Das SAML-Protokoll ermöglicht das Single Sign-On (SSO) über eine Abfolge von Nachrichten, die an den Browser gesendet und von ihm empfangen werden und die Informationen zwischen Fusion und der SAML-Behörde, die als Identitätsanbieter (IDP) fungiert, weiterleiten. Um Fusion für SAML zu konfigurieren, müssen Sie die Informationen über die SAML-Autorität als Teil des Konfigurationsprozesses der Sicherheitsumgebung registrieren. Neben der Konfiguration des Fusion-Sicherheitsbereichs müssen Sie auch den SAML-Identitätsanbieter so konfigurieren, dass er die Fusion-Anwendung erkennt.

Sobald Fusion für einen SAML-Realm konfiguriert ist, wird dieser Realm der Liste der verfügbaren Realms im ersten Anmeldefenster von Fusion hinzugefügt. Wenn der SAML-Realm aus der Liste der verfügbaren Realms ausgewählt wird, leitet der Browser an die IDP weiter, die die Benutzerauthentifizierung durchführt. Nach erfolgreicher Authentifizierung sendet die IDP eine Antwort an den Browser zurück, die Authentifizierungs- und Autorisierungsinformationen sowie die URL der Fusion-Anwendung enthält. Der Browser leitet zurück zur Fusion-URL und gibt die SAML-Nachricht mit den Authentifizierungs- und Autorisierungsinformationen des Benutzers weiter. Fusion stellt dann ein Session-Cookie aus, das für den nachfolgenden Benutzerzugriff verwendet wird.

Kerberos und SPNEGO

Kerberos

Der Name Kerberos stammt aus der griechischen Mythologie, wo Kerberos (oder Cerberus) der wilde dreiköpfige Wachhund von Hades, dem ursprünglichen Höllenhund, ist. Die Nachrichten des Kerberos-Protokolls sind gegen Abhör- und Wiederholungsangriffe geschützt. Anstatt Passwörter im Klartext über das Netzwerk zu senden, werden verschlüsselte Passwörter verwendet, um zeitabhängige Tickets für die Authentifizierung zu erstellen.

Kerberos verwendet symmetrische Kryptographie und eine vertrauenswürdige dritte Partei, die als Key Distribution Center (KDC) bezeichnet wird, um Benutzer für eine Reihe von Netzwerkdiensten zu authentifizieren, wobei ein Benutzer entweder ein Endbenutzer oder ein Client-Programm sein kann. Die von diesem KDC verwalteten Computer und alle sekundären KDCs bilden einen Realm. Ein kerberisierter Prozess ist ein Prozess, der so konfiguriert wurde, dass er Tickets von einem KDC erhalten und mit Kerberos-fähigen Diensten verhandeln kann.

In den nächsten Absätzen werden die einzelnen Schritte des Kerberos-Protokolls beschrieben. Es handelt sich dabei um Hintergrundinformationen, Sie können also zum nächsten Abschnitt über SPNEGO übergehen, denn das ist ziemlich trockener Stoff. Wir haben versucht, Margot Robbie dazu zu bringen, es für Sie zu erklären, aber sie war nicht verfügbar. Stattdessen haben wir das folgende Diagramm aus einer alten MSDN-Dokumentation heruntergeladen, da das Active Directory von Microsoft Kerberos für seine Sicherheitsinfrastruktur verwendet. Es zeigt die wesentlichen Schritte des Kerberos-Protokolls, von der ersten Anmeldung über die Authentifizierung und Autorisierung bis hin zum Anwendungszugriff:

Im Folgenden finden Sie eine Zusammenfassung der Schritte, die in der obigen Karikatur skizziert sind, mit Angabe der wichtigsten Akronyme, die Sie kennen müssen, um Fusion für die Kerberos-Authentifizierung zu konfigurieren:

• Schritt 1. Um sich anzumelden, sendet der Client eine Nachricht an den Autorisierungsserver (AS) des KDC, um ein Ticket (TGT) zu erhalten.
• Schritt 2. Der Autorisierungsserver prüft die Zugriffsrechte des Benutzers und sendet ein verschlüsseltes TGT und einen Sitzungsschlüssel zurück. An dieser Stelle wird der Benutzer zur Eingabe eines Passworts aufgefordert. Das Klartextpasswort wird verschlüsselt, bevor es an den AS gesendet wird. Wenn die Authentifizierung erfolgreich war, ist das TGT des Benutzers für Serviceanfragen gültig.

Die Schritte 1 und 2 erfolgen nur bei der Anmeldung des Benutzers im Kerberos-Bereich. Danach werden der TGT und der Sitzungsschlüssel verwendet, um Zugang zu den Diensten in diesem Bereich zu erhalten.

• Schritt 3. Um auf einen kerberisierten Dienst zuzugreifen, sendet der Client eine Nachricht an den Ticket Granting Service (TGS) des KDC, die Identitätsinformationen enthält, die mit dem in Schritt 2 erhaltenen Sitzungsschlüssel verschlüsselt wurden.
• Schritt 4. Der TGS prüft die Anfrage und erstellt ein zeitabhängiges Ticket für den angeforderten Dienst.
• Schritt 5. Die Client-Anwendung sendet nun eine Dienstanfrage an den Server, die das in Schritt 4 erhaltene Ticket sowie die mit dem in Schritt 2 erhaltenen Sitzungsschlüssel verschlüsselten Identitätsinformationen enthält. Der Server prüft, ob das Ticket und die Identitätsdaten übereinstimmen und gewährt dann den Zugriff auf den Dienst.

SPNEGO

Wenn eine Client-Anwendung einen kerberisierten Dienst nutzen möchte, muss der Client ebenfalls kerberisiert sein, damit er den notwendigen Ticket- und Nachrichtenaustausch unterstützen kann. Da Fusion ein Webdienst ist, der entweder in einem Browser oder über HTTP-Anfragen an die REST-API von Fusion verfügbar ist, muss die für den Zugriff auf Fusion verwendete Webanwendung in der Lage sein, das Kerberos-Protokoll auszuführen, damit der Endbenutzer auf Fusion zugreifen kann.

SPNEGO wurde entwickelt, um Kerberos auf Webanwendungen auszuweiten, die das Standard-HTTP-Protokoll verwenden, beginnend mit dem Internet Explorer. Sowohl IE als auch Safari unterstützen SPNEGO sofort, während Firefox und Chrome eine zusätzliche Konfiguration erfordern. Das Unix-Befehlszeilendienstprogramm curl unterstützt ebenfalls SPNEGO; es kann mit der Befehlszeilenoption negotiate auf einen kerberisierten Webdienst zugreifen.

Wenn ein Fusion-Benutzer, der zu einer Kerberos-Sicherheitsdomäne gehört, über eine Webanwendung, die SPNEGO unterstützt, eine Anfrage an die kerberisierte Fusion-Benutzeroberfläche sendet, sendet die Webanwendung eine SPNEGO-Anfrage über HTTP oder HTTPS an Fusion und Fusion kommuniziert mit dem Kerberos-KDC, um die Identität und den Autorisierungsstatus dieses Benutzers zu ermitteln. Wenn sich der Benutzer nicht beim KDC/Authentifizierungsdienst authentifiziert hat, sendet Fusion eine 401-Antwort an die Webanwendung, die einen Negotiate-Header enthält. Diese Status-/Header-Antwort veranlasst SPNEGO-kompatible Clients, ein lokales Ticket aus ihrem Kerberos-Ticketfach zu holen, das sie dann verschlüsseln und an Fusion zurücksenden. Fusion entschlüsselt das Ticket und führt eine SPN.doAs(user) Authentifizierungsanfrage an den KDC/Authentifizierungsdienst durch. Je nach Ergebnis führt Fusion entweder die ursprüngliche Anfrage aus (zusammen mit einem Sitzungs-Cookie) oder gibt eine 401 (ohne Negotiate) an den Browser zurück.

Fusion Konfiguration

Die Konfiguration eines neuen Sicherheitsbereichs kann nur von einem Fusion-Benutzer vorgenommen werden, der über Admin-Rechte verfügt. Um einen neuen Sicherheitsbereich in der Fusion-Benutzeroberfläche zu konfigurieren, wählen Sie im Menü „Anwendungen“ den Menüpunkt „Zugriffskontrolle“. Daraufhin wird das Panel Zugriffskontrolle mit dem Unter-Panel „Sicherheitsbereiche“ angezeigt. Klicken Sie im Unterbereich „Sicherheitsbereiche“ auf die Schaltfläche „Sicherheitsbereich hinzufügen“:

Dies öffnet ein Editor-Panel für einen neuen Security Realm, das Steuerelemente und Eingaben für alle erforderlichen und optionalen Konfigurationsinformationen enthält. Der Name der Sicherheitsdomäne muss eindeutig sein. Es gibt ein Pulldown-Menü, aus dem Sie den Realm-Typ auswählen können:

Konfigurieren von Fusion für einen SAML-Sicherheitsbereich

Um einen SAML-Realm zu konfigurieren, ist der Realm-Typ „SAML“. In der Fusion-Benutzeroberfläche sind für die Konfiguration eines SAML-Realms die folgenden Informationen erforderlich:

• Identitätsanbieter-URL – die URL, die von der SAML-Autorität für Single Sign-On verwendet wird. Normalerweise eine URL, die auf „saml/sso“ endet, z.B. „https://www.my-idp.com/<my-app-path>/sso/saml“.
• Ausgeber – SAML-Ausgeber-ID. Eine eindeutige ID für diese Behörde, z.B. „http://www.my-idp.com/exk686w2xi5KTuSXz0h7“.
• Zertifikats-Fingerabdruck – der Inhalt des Zertifikats der SAML-Behörde, ohne den Zertifikatskopf und -fuß. Sie müssen dieses Zertifikat vom SAML-Identitätsanbieter erhalten. Das Zertifikat ist eine Textdatei mit zwei Kopf- und Fußzeilen, in denen „BEGIN CERTIFICATE“ bzw. „END CERTIFICATE“ steht. Der Fingerabdruck besteht aus den Zeilen zwischen der Kopfzeile und der Fußzeile. Sie können diese Informationen ausschneiden und in das Textfeld auf der Fusion-Benutzeroberfläche einfügen.
• Attribut Benutzer-ID – ein optionales Attribut. Der Identity Provider enthält die Benutzerdatenbank. Standardmäßig ist der Fusion-Benutzername derselbe wie der dem Identity Provider bekannte Anmeldename. Wenn ein anderes Feld oder Attribut in dem vom IDP gespeicherten Benutzerdatensatz als Fusion-Benutzername verwendet werden soll, ist dieser Attributname der Wert des Attributs Benutzer-ID. Um zu wissen, ob Sie das Attribut Benutzer-ID angeben müssen oder nicht, müssen Sie in der Lage sein, die von der IDP gespeicherte Benutzerdatenbank zu untersuchen.

Zusätzlich zur Konfiguration von Fusion für SAML müssen Sie Fusion bei der SAML-IDP registrieren. Der Umfang der Informationen variiert je nach SAML-Autorität.

Alle Systeme benötigen die Fusion-URL, an die nach erfolgreicher Anmeldung weitergeleitet wird. Dies ist das Protokoll, der Server und der Port für die Fusion-Anwendung sowie der Pfad „api/saml“, z.B. „https://www.my-fusion-app.com:8764/api/saml“. Wenn die Fusion-Anwendung hinter einem Load-Balancer läuft, dann ist diese URL die Load-Balancer-URL plus Pfad „api/saml“. Beachten Sie, dass der Load-Balancer session-sticky sein sollte, damit die Abfolge der Nachrichten, aus denen das SAML-Protokoll besteht, erfolgreich zu Ende geführt werden kann.

Einige Behörden können zusätzliche Informationen verlangen. Insbesondere das SAML 2.0-Tag „AudienceRestriction“ kann Teil der SAML-Nachricht sein. Dieses Tag gibt die Domäne an, für die die SAML-Vertrauensbedingungen gültig sind. Dies ist in der Regel die Domäne, in der die Fusion-App ausgeführt wird, z.B. „https://www.my-fusion-app“.

Beispiele für Konfigurationen finden Sie in der Fusion-Dokumentation.

Konfigurieren von Fusion für einen Kerberos-Sicherheitsbereich

Wenn die Fusion-Anwendung, die in einem Kerberos-Sicherheitsbereich läuft, mit anderen Ressourcen in diesem Bereich interagiert, ist es wichtig, dass Fusion über die richtige Kerberos-Autorisierung für den Zugriff auf diese Ressourcen verfügt. Dies wird durch die Identität und die Anmeldeinformationen von Fusion bestimmt. Um diese Informationen zu klären, müssen Sie fast immer mit dem Systemadministrator zusammenarbeiten, der Kerberos verwaltet. Bringen Sie Geschenke mit.

Um einen neuen Kerberos-Sicherheitsbereich zu konfigurieren, ist der Bereichstyp entweder „Kerberos“ oder „LDAP“:

• Um einen Bereich zu konfigurieren, der Kerberos für die Authentifizierung verwendet und der keinen zugehörigen LDAP-Server für Berechtigungen auf Gruppenebene hat, wählen Sie die Option „Kerberos“.
• Um einen Bereich zu konfigurieren, der Kerberos für die Authentifizierung verwendet und der auch die Mitgliedschaft und die Berechtigungen auf Gruppenebene von einem LDAP-Server abruft, wählen Sie die Option „LDAP“ und dann im Abschnitt „Authentifizierungsmethode“ der LDAP-Bereichskonfiguration die Option „Kerberos“, wie hier gezeigt:

Ein Kerberos-Sicherheitsbereich erfordert zwei Informationen:

• Service Principal Name – dies ist der Name des Fusion-Dienstes selbst in der Kerberos-Datenbank.
• Keytab Path – die Keytab-Dateien enthalten die verschlüsselten Identitätsdaten von Fusion, die Fusion im Rahmen des oben beschriebenen Protokolls an den KDC sendet.

Das übliche Szenario in einem Unternehmen ist, dass ein Kerberos-Administrator einen Dienstprinzipal mit einem zufälligen Schlüsselpasswort erstellt. Anschließend erstellt der Administrator eine Schlüsseltabelle, die dann für die Authentifizierung des Fusion-Dienstes verwendet wird.

In der Fusion-Dokumentation zur Konfiguration von Fusion für Kerberos finden Sie weitere Einzelheiten zu keytab-Dateien und wie Sie sie testen können.

Für Kerberos-Sicherheitsbereiche, die kein LDAP verwenden, zeigt die Fusion-Benutzeroberfläche auch Eingaben für den optionalen Konfigurationsparameter „Kerberos Name Rules“ an. Damit legen Sie fest, wie der Fusion-Benutzername des Kerberos-Benutzers lautet. Der Standard-Fusion-Benutzername wird durch Verkettung des Kerberos-Benutzernamens, des Symbols „@“ und des Kerberos-Domänennamens gebildet. So hat z.B. der Benutzer „any.user“ in der Kerberos-Domäne „MYORG.ORG“ den Fusion-Benutzernamen „any.user@MYORG.ORG“.

Diskussion

Fusion bietet verschiedene Arten von Sicherheitsbereichen für verschiedene Arten von Single Sign-On-Mechanismen. Der Unterschied zwischen der LDAP-Konfiguration, die im vorherigen Beitrag dieser Serie Leveraging LDAP behandelt wurde, und den hier vorgestellten Kerberos- und SAML-Mechanismen besteht darin, dass bei letzteren der Dialog zwischen Fusion und den Servern, der die Authentifizierung und Autorisierung ermöglicht, über den Browser vermittelt wird.

Damit eine Fusion-Anwendung mit einem Kerberos- oder SAML-Realm arbeiten kann, sind zusätzliche Konfigurationsschritte außerhalb von Fusion erforderlich. In einer Kerberos-Umgebung gibt es eine einzige Kerberos-Autorität. Fusion selbst ist als Dienst beim Kerberos-KDC registriert. Sobald Fusion und der Browser richtig konfiguriert sind, kann Fusion die Schritte im Kerberos/SPNEGO-Protokoll ausführen. Bei SAML ist alles verteilt, d.h. die Fusion-Anwendung muss für die Zusammenarbeit mit der SAML-Autorität konfiguriert werden und die SAML-Autorität muss für die Zusammenarbeit mit Fusion konfiguriert werden. Die Überprüfung Ihrer Arbeit ist ebenfalls komplizierter. Da Fusion nicht direkt mit dem Server kommuniziert, bieten die Konfigurationspanels für Kerberos und SAML keine Kontrolle für „Testeinstellungen“.

Die Konfiguration von Fusion für Single Sign-On ist sinnvoll, wenn eine enge Kopplung zwischen den Eigentümern und Berechtigungen für die Dokumente in Ihrer Sammlung und den einzelnen Benutzern, die Zugriff darauf haben, besteht. Wenn Ihre Suchanwendung eine Suche über eine Sammlung mit Sicherheit auf Dokumentenebene über ACLs erfordert, dann müssen Sie für alle Benutzer, die auf diese Dokumente zugreifen können, ein Benutzerkonto anlegen. Andernfalls ist der systemeigene Authentifizierungsmechanismus von Fusion für Situationen geeignet, in denen die Benutzer des Systems in verschiedene Kategorien fallen und die Mitglieder einer Kategorie austauschbar sind. In diesem Fall können Sie eine Reihe von generischen Benutzern definieren, einen pro Kategorietyp, und ihnen entsprechende Berechtigungen zuweisen.

Dies ist der vierte Artikel in einer Reihe von Artikeln über die Sicherung Ihrer Daten in Lucidworks Fusion. Secure Fusion: SSL-Konfiguration behandelt die Sicherheit der Transportschicht und Secure Fusion: Authentifizierung und Autorisierung behandelt allgemeine Sicherheitsmechanismen auf Anwendungsebene in Fusion. Dieser Artikel und der vorherige Artikel Secure Fusion: Leveraging LDAP zeigen, wie Fusion so konfiguriert werden kann, dass es mit externen Autorisierungsdiensten zusammenarbeitet und so bei Bedarf fein abgestufte Sicherheit bietet. Fusion analysiert Ihre Daten auf Ihre Art und Weise, gemäß Ihren Zugriffsregeln.