Konfiguration von Trusted Peer Authentication für Mindbreeze InSpire

Copyright ©

Mindbreeze GmbH, A-4020 Linz, .

Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Marken der jeweiligen Hersteller.

Diese Unterlagen sind streng vertraulich. Durch die Übermittlung und Präsentation dieser Unterlagen alleine werden keine Rechte an unserer Software, an unseren Dienstleistungen und Dienstleistungsresultaten oder sonstigen geschützten Rechten begründet. Die Weitergabe, Veröffentlichung oder Vervielfältigung ist nicht gestattet.

Aus Gründen der einfacheren Lesbarkeit wird auf die geschlechtsspezifische Differenzierung, z.B. Benutzer/-innen, verzichtet. Entsprechende Begriffe gelten im Sinne der Gleichbehandlung grundsätzlich für beide Geschlechter.

EinführungPermanenter Link zu dieser Überschrift

Typischerweise melden sich Benutzer bei der Suche direkt am Client Service an. Dazu wird eine der Authentifizierungsvarianten Kerberos, SAML oder CAS verwendet.

Mit Trusted Peer Authentifizierung ist es möglich, dass der Benutzername, der für die Berechtigungsprüfung der Suchresultate verwendet wird, mit der Anfrage gesendet wird. Damit dadurch nicht jeder Benutzer im Namen eines anderen suchen kann, muss der Aufrufer einen Beweis erbringen, dass ihm vertraut werden kann.

Hierfür gibt es folgende zwei Möglichkeiten:

  1. die Anfrage verwendet ein Clientzertifikat, das von einem in der Konfiguration hinterlegten CA-Zertifikat signiert wurde
  2. die Anfrage enthält einen OAuth 2.0 Bearer Token eines konfigurierten OAuth-Servers.

Trusted Peer Authentifizierung wird unter anderem verwendet, wenn

  • die Suche in eine bestehende Anwendung eingebunden wird, wo bereits eine Authentifizierung stattfindet, oder
  • die API direkt verwendet wird.

VoraussetzungenPermanenter Link zu dieser Überschrift

Damit Client Services Trusted Peer Authentifizierung nutzen können, muss die Kommunikation zwischen Client- und Query Service mit Trusted Peer Authentifizierung mit Zertifikaten abgesichert sein.

Trusted Peer Authentifizierung mit ZertifikatenPermanenter Link zu dieser Überschrift

Werden Zertifikate für die Vertrauensbeziehung zwischen Anfragesteller und Service verwendet, muss folgendes gegeben sein:

  • auf der Appliance ist ein CA-Zertifikat installiert und als Trusted Peer markiert
  • der Anfragesteller sendet die Anfrage mit einem von diesem CA-Zertifikat signierten Clientzertifikat
  • die Eigenschaft Subject des Clientzertifikats stimmt mit einem konfigurierten regulären Ausdruck überein (nur bei Client Services)

Anforderungen an die ZertifikatePermanenter Link zu dieser Überschrift

Wichtig: Das CA-Zertifikat darf ausschließlich für die Vertrauensbeziehung verwendet werden. Jeder Anfragesteller erhält ein mit diesem CA-Zertifikat signiertes Clientzertifikat. Dadurch werden die Missbrauchsmöglichkeiten eingeschränkt. Es ist beispielsweise fahrlässig das CA-Zertifikat zu verwenden, dass für SSL Server-Zertifikate im Unternehmen verwendet wird, sonst würde jedem SSL Server-Zertifikat vertraut.

Das CA-Zertifikat muss als PEM-Datei vorliegen. Der Private Key muss nicht enthalten sein.

Für die Kommunikation zwischen Client- und Query Service muss ein Clientzertifikat im PKCS #12-Format und ohne Passwort installiert sein.

Es kann pro Installation nur ein CA-Zertifikat als Trusted Peer Zertifikat verwendet werden.

Installation und Auswahl der ZertifikatePermanenter Link zu dieser Überschrift

Öffnen Sie die Konfigurationsoberfläche

Navigieren Sie zum Reiter Certificates

Wählen Sie unter Certificate in der Auswahl CA aus

Wählen Sie unter Certificate das zu installierende CA-Zertifikat (.pem) aus

Klicken Sie Upload

Aktivieren Sie unter Available CAs die Option Trusted Peer beim neu installierten Zertifikat damit wird das Zertifikat automatisch für alle Query Services verwendet

Wählen Sie unter Certificate in der Auswahl SSL aus

Wählen Sie unter Certificate das zu installierende Clientzertifikat (.pem) aus

Klicken Sie Upload

Navigieren Sie zum Reiter Client Services

Wählen Sie unter Trusted Peer Communication To Query Services – Credential Certificate das installierte Clientzertifikat aus

Aktivieren Sie die Einstellung Trusted Peer Communication To Query Services  –Authentication Generates Trusted Peer Credentials

Aktivieren der Trusted Peer Authentifizierung mit Zertifikaten am Client ServicePermanenter Link zu dieser Überschrift

Navigieren Sie zum Reiter Client Services

Öffnen Sie die Einstellungen des gewünschten Client Services

Aktivieren Sie Trusted Peer Access Using Certificates - Enable Trusted Peer Access Using Certificates

Hinterlegen Sie einen regulären Ausdruck mit dem die Eigenschaft Subject des Clientzertifikats geprüft wird unter Trusted Peer Access Using Certificates - Certificate Subjects Trusted for Identity Delegation (Java, Groß- und Kleinschreibung werden berücksichtigt). Die Option muss gesetzt werden.

Trusted Peer Authentifizierung mit OAuth 2.0 Bearer TokenPermanenter Link zu dieser Überschrift

Bei der Authentifizierung mit OAuth 2.0 Bearer Token muss der OAuth-Server hinterlegt werden. Trusted Peer Authentifizierung wird nur Benutzern erlaubt, denen eine konfigurierte Rolle zugewiesen ist. Die einzelnen Konfigurationswerte erfragen Sie am besten bei ihrem OAuth-Server-Administrator.

Navigieren Sie zum Reiter Client Services

Öffnen Sie die Einstellungen des gewünschten Client Services

Aktivieren Sie Trusted Peer Access Using OAuth 2.0 Bearer Token - Enable Trusted Peer Access Using OAuth 2.0 Bearer Token

Hinterlegen Sie die Adresse des OAuth-Servers in Auth Server URL

Kontrollieren Sie die restlichen Einstellungen in Trusted Peer Access Using OAuth 2.0 Bearer Token und ändern Sie wenn gewünscht

Realm

der zu verwendende OAuth Realm, Details finden Sie bei Ihrem OAuth-Server

Resource

die zu verwendende OAuth Resource, Details finden Sie bei Ihrem OAuth-Server (bei einigen OAuth-Servern auch Client genannt)

SSL Security for Communication with Auth Server

legt fest, wie die HTTPS-Verbindung zum Auth Server geprüft wird:

Validate Certificate and Hostname

das Serverzertifikat des Auth Servers muss von einem vertrauten Zertifikat ausgestellt sein und der Hostnamen muss mit dem der Option Auth Server URL übereinstimmen

Validate Hostname

der Hostname im Serverzertifikat des Auth Servers muss mit dem der Option Auth Server URL übereinstimmen

No Validation (do not use in production)

das Serverzertifikat des Auth Servers wird immer akzeptiert

Role Trusted for Identity Delegation

nur Benutzer, die dieser Rolle zugeordnet sind, dürfen Trusted Peer Authentication durchführen

Senden des BenutzernamensPermanenter Link zu dieser Überschrift

Der Benutzername kann entweder als HTTP-Header oder in der Anfrage gesendet werden.

Benutzername als HTTP-HeaderPermanenter Link zu dieser Überschrift

Der Benutzername wird als HTTP-Header X-Auth-User übertragen.

Beispiel für das Senden des Benutzernamens als HTTP-Header

X-Auth-User: max.mustermann

Benutzername als Teil der AnfragePermanenter Link zu dieser Überschrift

Bei api.v2-Anfragen kann der Benutzername in der Eigenschaft user_context.username übermittelt werden.

Beispiel für das Senden des Benutzernamens als Teil einer api.v2.search-Anfrage

{

  "user_context": {

    "user_name": "max.mustermann"

  },

  "properties": [

    {

      "formats": [

        "HTML"

      ],

      "name": "title"

    }

  ],

  "count": 5,

  "query": {

    "unparsed": "mindbreeze"

  }

}

Auswahl der Quelle des BenutzernamensPermanenter Link zu dieser Überschrift

Die Option Trusted Peer Identity Extraction - Identity Extraction Order legt fest wie der Benutzername gesendet werden kann. Folgende Auswahlmöglichkeiten stehen zur Verfügung:

Header, Request

ist der Benutzername im X-Auth-User HTTP-Header gesetzt, wird er verwendet. Wenn nicht, wird der Benutzername aus der Anfrage verwendet.

Header

der Benutzername im X-Auth-User HTTP-Header wird er verwendet. Die Anfrage wird nicht berücksichtigt.

Request

der Benutzername aus der Anfrage wird verwendet. Der X-Auth-User HTTP-Header wird nicht berücksichtigt.

Request, Header

ist der Benutzername in der Anfrage gesetzt wird er verwendet. Wenn nicht, wird der Benutzername aus dem X-Auth-User HTTP-Header verwendet.