Secure Fusion: Authentifizierung und Autorisierung

Dies ist der zweite Teil einer Serie von Artikeln über die Sicherung Ihrer Daten in Lucidworks Fusion. Hier ist Teil…

Dies ist der zweite Teil einer Serie von Artikeln über die Sicherung Ihrer Daten in Lucidworks Fusion. Hier ist Teil 1.

Dieser Beitrag behandelt die grundlegenden Sicherheitsmechanismen von Fusion auf Anwendungsebene. Auf der Anwendungsebene bietet Fusions Sicherheit über:

• Authentifizierung – Benutzer müssen sich mit einem Benutzernamen und einem Passwort anmelden.
• Autorisierung – jeder Benutzername ist mit einer oder mehreren Berechtigungen verbunden, die die Fusion REST-API-Anfragen festlegen, auf die er Zugriff hat. Die Berechtigungen können auf bestimmte Endpunkte und Pfadparameter beschränkt werden.

Fusion speichert diese Informationen in Apache ZooKeeper(beachten Sie die Hinweise in diesem Beitrag über die Verwendung von ZooKeeper). ZooKeeper sorgt dafür, dass diese Informationen sicher und für alle Fusion-Komponenten in der gesamten Bereitstellung jederzeit verfügbar sind.

Benutzer und Reiche

Ein Realm in einer Java EE-Anwendung ist eine vollständige Datenbank mit Benutzern und Gruppen, die durch dieselbe Art der Authentifizierung gesteuert werden. Ein Realm wird als Teil einer HTTP-Anfrage während der Basisauthentifizierung angegeben. In Fusion wird diese Information durch einen Security Realm gekapselt, der durch eine eindeutige ID, einen Realm-Namen und den Typ des Authentifizierungsmechanismus definiert ist.

Fusion kann für die folgenden Realm-Typen konfiguriert werden:

• Nativ – Fusion verwaltet alle Authentifizierungs- und Berechtigungsinformationen direkt. Fusion-Benutzerkonten werden entweder über die Fusion-Benutzeroberfläche oder die REST-API erstellt und verwaltet. Die gesamte Benutzerdatenbank wird in ZooKeeper gespeichert. Gespeicherte Passwörter werden mit bcrypt verschlüsselt, dem stärkstmöglichen Verschlüsselungsalgorithmus, der für alle JDKs verfügbar ist. Der native Realm ist die Heimat des Fusion-Admin-Benutzers und ist der Standard-Realm-Typ.
• LDAP – Fusion speichert einen lokalen Benutzerdatensatz in ZooKeeper, und die Authentifizierung erfolgt über den LDAP-Server. Die Fusion-Benutzerkennung entspricht direkt dem LDAP-Distinguished Name (DN).
• Kerberos – Fusion speichert einen lokalen Benutzereintrag in ZooKeeper und eine Zuordnung zum Kerberos-Prinzipal. SPNEGO wird für die Authentifizierung über Kerberos verwendet.

Dieser Beitrag befasst sich nur mit der Authentifizierung und Benutzerverwaltung im nativen Sicherheitsbereich von Fusion. In den nächsten Beiträgen werden die Sicherheitsbereiche LDAP und Kerberos behandelt.

Authentifizierung: Nur für Mitglieder

Fusion-Anmeldungen erfordern einen Benutzernamen, ein Passwort und einen Authentifizierungsbereich. Benutzernamen sind innerhalb eines Bereichs eindeutig. Fusion erstellt eine weltweit eindeutige Benutzer-ID für alle Benutzer auf der Grundlage der Kombination aus Benutzername und Bereich.

In der Fusion-Benutzeroberfläche bietet der Anmeldebildschirm ein Pulldown-Menü für alle konfigurierten Security Realms. Wenn keine anderen Sicherheitsbereiche konfiguriert wurden, ist die einzige Auswahl der „native“ Bereich.

Das Systemadministratorkonto gehört zum nativen Bereich von Fusion. Beim ersten Start ist das erste angezeigte UI-Panel das Panel „Admin-Kennwort festlegen“:

Sie müssen die Fusion-Benutzeroberfläche starten, um das Passwort für den Administrator festzulegen, damit Sie mit Fusion arbeiten können. Durch das Festlegen des Kennworts wird das Konto erstellt. Andernfalls haben Sie ein System ohne Benutzerkonten, was es unmöglich macht, eine ordnungsgemäß autorisierte Anfrage zu erstellen: keine Autorisierung, kein Service.

Sobald das Passwort bestätigt wurde, registriert Fusion das Konto „admin“ in ZooKeeper. Der Benutzer admin hat alle Systemprivilegien; wenn Sie als admin angemeldet sind, haben Sie Zugriff auf alle Daten und Konfigurationsinformationen. In einer Produktionsumgebung sollte es jedoch mindestens so viele Benutzerkonten geben, wie es verschiedene Arten von Benutzern gibt.

Wenn Ihre Suchanwendung eine Suche über eine Sammlung mit Sicherheit auf Dokumentenebene über ACLs erfordert, dann müssen Sie ein Benutzerkonto für alle Benutzer erstellen, die auf diese Dokumente zugreifen können. Dies kann in Verbindung mit LDAP geschehen oder indem Sie Fusion-Benutzer direkt im nativen Bereich anlegen. In letzterem Fall müssen Sie sicherstellen, dass: die Benutzernamen mit den ACLs auf den Dokumenten übereinstimmen und die für die Indizierung verwendete Datenquelle so konfiguriert ist, dass sie die ACLs zusammen mit den Dokumenteninhalten indiziert. Wenn Sie keine Sicherheit auf Dokumentenebene haben, müssen Sie nur so viele Benutzerkonten definieren, wie Sie Benutzertypen haben.

Autorisierung über Rollen und Berechtigungen: Jedem nach seinem Bedürfnis

Fusion-Berechtigungen legen den Zugriff auf die Fusion REST-API-Endpunkte fest. Wenn ein Benutzer eine Anfrage stellt, verwendet der Autorisierungsmechanismus von Fusion die eindeutige Benutzer-ID, um die Benutzerberechtigungen aus dem entsprechenden Bereich zu erhalten.

Der Fusion REST-API-Dienst User dient zur Erstellung und Verwaltung von Benutzerberechtigungen. Ein Benutzer mit vollen Rechten für den Dienst User kann Benutzerkonten erstellen und verwalten. Um diesen Prozess zu beschleunigen, erstellt Fusion beim ersten Start den Benutzer admin. Um Benutzerkonten in der Fusion-Benutzeroberfläche zu verwalten, wählen Sie in der oberen Menüleiste im Pulldown-Menü „Anwendungen“ den Eintrag „Zugriffskontrolle“:

Das Panel „Zugriff“ hat drei Unter-Panels: „BENUTZER“, „ROLLEN“ und „SICHERHEITSREALEN“. Benutzerkonten werden über die Schaltfläche „Benutzer hinzufügen“ des Unterpanels „BENUTZER“ erstellt:

Die folgenden Informationen sind erforderlich, um ein neues Benutzerkonto zu erstellen: Benutzername, Realm und Passwort. Alle anderen Angaben sind optional. Solange ein Benutzer jedoch nicht über eine oder mehrere Berechtigungen verfügt, kann er in Fusion nichts tun.

Eine Berechtigungsspezifikation besteht aus zwei oder drei Informationen:

• Erlaubte HTTP-Anfragemethoden.
• Pfad der REST-API-Dienste, der Platzhalter oder benannte Variablen enthalten kann. Alle Aufrufe der REST-API beginnen mit „api/apollo“, gefolgt vom Namen des Dienstes und allen Methoden und Parametern. Die Angabe der Berechtigungen umfasst alles, was auf „api/apollo“ folgt.
• Erlaubte Werte für alle benannten Variablen im Pfad.

Berechtigungsangaben werden als Zeichenkette kodiert, wobei das Doppelpunktzeichen „:“ als Trennzeichen zwischen den Berechtigungselementen verwendet wird:

• Die Methodenangabe listet die erlaubte(n) HTTP-Methode(n) auf, getrennt durch Kommas.
• Der Endpunkt kann Wildcards enthalten. Das Platzhaltersymbol ‚*‘ entspricht allen möglichen Werten für ein einzelnes Pfadfragment und zwei Platzhalter entsprechen allen möglichen Werten für eine beliebige Anzahl von Pfadfragmenten. Ein Pfadfragment kann eine benannte Variable sein, die in geschweifte Klammern eingeschlossen ist: „{Variablenname}“. Variablen werden verwendet, wenn ein Platzhalter zu freizügig und ein einzelnes Pfadfragment zu restriktiv wäre.
• Die Komponente Variablenspezifikation gibt den eingeschränkten Wert oder die eingeschränkten Werte für alle benannten Variablen im Pfad an. Jede Spezifikation besteht aus dem Variablennamen, gefolgt von „=“ (dem Gleichheitszeichen), gefolgt von einem oder mehreren Werten, die durch Kommata getrennt sind. Wenn die Endpunktspezifikation mehrere Variablen enthält, wird das Semikolonzeichen „;“ als Trennzeichen zwischen den Parameterangaben verwendet.

Nachfolgend finden Sie Beispiele für Genehmigungsspezifikationen und deren Funktion:

• GET:/query-pipelines/*/collections/*/select – Suchzugriff auf jede Fusion-Sammlung.
• GET,PUT:/collections/Collection345/synonyms/** – die Erlaubnis, Synonyme für die Sammlung „Collection345“ zu bearbeiten.
• GET:/collections/{id}:id=Collection345,Collection346 – Lesezugriff auf Sammlungen mit den Namen „Collection345“ und „Collection346“.

Mit Platzhaltern können Sie ganz einfach umfassenden Zugriff auf Fusion-Dienste gewähren. Die Berechtigungen für den Benutzer admin können in eine einzige Zeile geschrieben werden:

GET,POST,PUT,DELETE,PATCH,HEAD:/**

Um den Zugriff auf eine Teilmenge der Funktionen von Fusion einzuschränken, ist eine Liste eng definierter Berechtigungen erforderlich. Um diesen Prozess zu erleichtern, bietet Fusion „Rollen“ an, die benannte Gruppen von Berechtigungen sind. Diese werden über das Panel „ROLEN“ der „Zugriffs“-Kontrollen verwaltet:

Beim ersten Start erstellt Fusion die folgenden benannten Rollen:

• admin – Superuser-Rolle – Zugriff auf alles, Berechtigungen wie oben beschrieben.
• collection-admin – Lese-/Schreibzugriff auf alle Abfragepipelines/-stufen und Sammlungen sowie Lesezugriff auf alle Berichte und Konnektoren.
• search – Nur-Lese-Zugriff auf Sammlungen und Berechtigungen, die für den Zugriff auf die Fusion Search UI erforderlich sind.
• ui-user – Zugriff auf die Fusion-Benutzeroberfläche nur zu Informationszwecken, ermöglicht dem Benutzer auch die Änderung seines Passworts.

Um zu sehen, wie die verschiedenen Berechtigungen funktionieren, erstelle ich, während ich als Admin-Benutzer angemeldet bin, einen neuen Benutzer mit dem Benutzernamen „demo-search-user“ und mit Berechtigungen für die Rolle „search“:

Als nächstes logge ich mich als Administrator aus und melde mich als „demo-search-user“ an. Wenn ich mich als „demo-search-user“ anmelde, ist die einzige Auswahl im Menü „Anwendungen“ „Sammlungen“. Wenn Sie eine Sammlung anzeigen, enthält das Menü „Home“ keine Optionen; das Einzige, was dieser Benutzer tun kann, ist die Durchführung von Suchvorgängen über das Bedienfeld „Suchen“.

Der Suchbenutzer kann Suchen durchführen, aber es gibt keine verfügbare Rolle für einen Datenanalysten, der die Dashboards von Fusion verwenden möchte. Um zu zeigen, wie Sie einen sehr begrenzten Satz von Berechtigungen für einen bestimmten Benutzer erstellen können, definiere ich eine Rolle namens „dashboards-collection-test“, die einem Benutzer den Zugriff auf das Dashboard von Fusion für eine Sammlung namens „test“ ermöglicht. Die Berechtigungen sind:

• GET:/solr/{id}/*:id=test– Nur-Lese-Zugriff auf die Sammlung mit dem Namen „test“
• GET:/solr/{id}/admin/luke:id=test – auch schreibgeschützter Zugriff
• GET:/solr/system_banana/* – Schreibgeschützter Zugriff auf Dashboards
• GET:/collections/system_banana – Nur-Lese-Zugriff auf die Sammlung, in der die Dashboard-Definitionen gespeichert sind

Im Panel „ROLEN“ erstelle ich die Rolle „dashboards-collection-test“ mit den oben genannten Berechtigungen:

Als nächstes erstelle ich einen Benutzer namens „demo-dashboard-user“. Dieser Benutzer hat die Rolle „dashboards-collection-test“ und hat auch Zugriff auf die UI-Dashboards und keine anderen Rollen oder UI-Zugriff. Wenn Sie sich als „demo-dashboard-user“ anmelden, ist das Hauptfenster der Benutzeroberfläche leer und die einzige Auswahlmöglichkeit im Anwendungsmenü ist „Dashboards“.

Ich kann ein Dashboard ohne Zeitreihen über die Sammlung „test“ erstellen:

Versuche, dieses Dashboard wieder in Solr zu speichern, schlagen fehl, da diese Rolle nur Lesezugriff gewährt.

Authentifizierung und Sitzungscookies

Wenn Fusion eine Anmeldeanfrage erhält, authentifiziert es den Benutzer, indem es sein verschlüsseltes Passwort aus ZooKeeper abruft und einen Passwort-Hash-Vergleich durchführt. Da dieser Vorgang sehr rechenintensiv ist, erstellt die Fusion-Benutzeroberfläche nach erfolgreicher Authentifizierung automatisch ein Sitzungs-Cookie, das die eindeutige Benutzerkennung enthält. Dieses Cookie wird für den Rest der Browsersitzung verwendet, obwohl es nach 45 Minuten Inaktivität abläuft.

Alle Anfragen an die Fusion REST-API erfordern entweder ein Paar aus Benutzernamen und Passwort oder das Session-Cookie, das die eindeutige Benutzer-ID enthält. Für Anwendungen, die Anfragen an die Fusion REST-API senden, kann der Fusion UI Service-Endpunkt „api/session“ verwendet werden, um dieses Cookie über eine POST-Anfrage zu generieren, deren Body aus einem JSON-Objekt besteht, das die Informationen zu Benutzername und Passwort enthält. Wenn Sie Fusion über SSL ausführen, werden diese Passwörter auf dem Weg über die Leitung sicher verschlüsselt. (Wenn Sie Fusion nicht über SSL betreiben, lesen Sie bitte den vorherigen Beitrag dieser Serie, um dies zu ändern).

Um zu sehen, wie Session-Cookies erzeugt und verwendet werden, verwenden wir das Befehlszeilentool curl. Der Befehl zur Erzeugung eines Sitzungscookies für den Benutzer admin mit dem Passwort „password123“ lautet:

curl 
 -c cookie -i -X POST -H "Content-type:application/json" -d @- -k 
 https://localhost:8764/api/session 
<<EOF
 { "username" : "admin" , "password" : "password123" }
EOF

Der Befehl curl nimmt eine beliebige Anzahl spezieller Argumente entgegen, gefolgt von der URL des Anfrageendpunkts. Für diejenigen unter Ihnen, die curl nicht fließend beherrschen, wird hier erklärt, was jeder Teil der obigen Beschwörungsformel bewirkt:

• -c : Dateiname der Cookies-Datei. Wenn sie existiert, werden die Cookies hinzugefügt. Sie können -c - verwenden, das in das Terminalfenster (std out) schreibt.
• -i : schließt den HTTP-Header in die Ausgabe ein. Wird hier verwendet, um das mit der Antwort zurückgegebene Cookie zu sehen.
• -X : Anfragemethode, in diesem Fall POST
• -H : Anfrage-Header. Der Endpunkt api/session erfordert Content-type:application/json.
• -d Übergeben Sie den POST-Body als Teil der Befehlszeilenanforderung. Um den Body aus einer Datei bereitzustellen, verwenden Sie die Syntax -d @<filename>. Das Argument -d @- liest die Daten von stdin.
• -k : unsicherer Modus – dies schaltet die Überprüfung des SSL-Zertifikats des Servers aus. Dies ist für dieses Beispiel notwendig, da der Server ein selbstsigniertes Zertifikat verwendet.
• <URL>: URL anfordern – https://localhost:8764/api/session, da Fusion lokal ausgeführt wird und für SSL konfiguriert ist.

Die letzte Zeile enthält die Daten des POST-Bodys, d.h. das JSON-Objekt, das das Paar Benutzername und Passwort enthält. Das Argument -d @- weist curl an, die Daten von stdin zu lesen. Das Shell-Format heredoc nimmt den gesamten Text zwischen der Zeile “ <<EOF“ und die abschließende Zeile „EOF“ und sendet sie an stdin. Auf diese Weise können Sie alle Argumente, einschließlich der Anfrage-URL, angeben, bevor Sie die gesamten POST-Daten eintippen. Wenn Sie, wie ich, manchmal vergessen, die URL nach allen Daten anzugeben, verwenden Sie heredoc.

Die Header-Ausgabe zeigt die Cookie-Informationen an:

HTTP/1.1 201 Created
Set-Cookie: id=996e4adf-bd04-4058-a926-8ea8ca08c05a;Secure;HttpOnly;Path=/api
Content-Length: 0
Server: Jetty(9.2.11.v20150529)

Die Cookie-Informationen in der Kopfzeile stimmen mit den Informationen in der Cookie-Datei überein:

> cat cookie

# Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_localhost     FALSE   /api    TRUE    0       id      996e4adf-bd04-4058-a926-8ea8ca08c05a

Sobald die Session-Cookie-Datei erstellt wurde, kann sie bei allen nachfolgenden Anfragen an die REST-API mitgesendet werden. Für den Befehlszeilen-Client curl wird das Flag -b verwendet, um den Inhalt der Cookie-Datei zusammen mit der Anfrage an den Server zu senden.

Der folgende Befehl sendet eine GET-Anfrage an den Fusion REST-API-Dienst Collections, um den Status der Sammlung „system_metrics“ zu überprüfen. Mit dem Flag -b wird ein frisch generierter Sitzungscookie gesendet. Wie zuvor ist das Flag -k erforderlich, da SSL Fusion ein selbstsigniertes Zertifikat verwendet:

> curl -b cookie -i -k https://localhost:8764/api/apollo/collections/system_metrics

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding, User-Agent
Content-Length: 278
Server: Jetty(9.2.11.v20150529)

{
  "id" : "system_metrics",
  "createdAt" : "2016-03-04T23:29:47.779Z",
  "searchClusterId" : "default",
  "commitWithin" : 10000,
  "solrParams" : {
    "name" : "system_metrics",
    "numShards" : 1,
    "replicationFactor" : 1
  },
  "type" : "METRICS",
  "metadata" : { }
}

Wenn das Sitzungscookie abgelaufen ist, gibt das System einen 401 Unauthorized Code zurück:

> curl -b cookie -i -k https://localhost:8764/api/apollo/collections/system_metrics

HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Content-Length: 31
Server: Jetty(9.2.11.v20150529)

{"code":"session-idle-timeout"}

Diskussion

Fusion bietet Sicherheit auf der Datentransportschicht über HTTPS und SSL. Secure Fusion: SSL-Konfiguration erklärt, wie dies funktioniert und zeigt Ihnen, wie Sie Fusion für SSL konfigurieren. Dadurch wird sichergestellt, dass Daten, die an und von Fusion gesendet werden, sicher verschlüsselt werden, so dass zwischengeschaltete Server nicht auf Ihre Daten zugreifen können.

In diesem Beitrag haben wir gesehen, wie die Authentifizierung und die Berechtigungen von Fusion zusammenarbeiten, um Ihre Daten vor unberechtigtem Zugriff zu schützen, und wie Sie Benutzerkonten und Berechtigungen direkt in Fusion verwalten können. Als praktisches Beispiel zeigen wir, wie Sie Fusion so konfigurieren, dass ein Benutzer nur Lesezugriff auf die Datenanalyse-Dashboards von Fusion für eine bestimmte Sammlung erhält. Als Bonus zeigen wir, wie Sie Sitzungscookies für eine schnelle Authentifizierung verwalten.

In den nächsten Blog-Beiträgen wird gezeigt, wie Fusion so konfiguriert werden kann, dass es die Benutzernamen, Passwörter und Gruppenmitgliedschaften des Sicherheitsmechanismus der Domäne abruft, in der Fusion ausgeführt wird. So wird sichergestellt, dass die in Fusion aufgenommenen Daten die gleichen Zugriffsrechte und den gleichen Schutz erhalten wie im Quell-Repository.