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.
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:
Trusted Peer Authentifizierung wird unter anderem verwendet, wenn
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.
Werden Zertifikate für die Vertrauensbeziehung zwischen Anfragesteller und Service verwendet, muss folgendes gegeben sein:
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.
Ö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
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
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.
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:
| ||||||
Role Trusted for Identity Delegation | nur Benutzer, die dieser Rolle zugeordnet sind, dürfen Trusted Peer Authentication durchführen |
Der Benutzername kann entweder als HTTP-Header oder in der Anfrage gesendet werden.
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
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"
}
}
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. |
Benutzergruppen können als HTTP-Header X-Auth-Groups übertragen werden.
Die Benutzergruppen müssen beistrichgetrennt und anschließend HTML form encodiert werden.
Beispiel für das Senden von Benutzergruppen als HTTP-Header:
X-Auth-Groups: marketing%2Cauthors%2Cquality%20assurance
Dies ergibt folgende Benutzergruppen:
marketing
authors
quality assurance
Mit HTTP-Headern ist es möglich zu der Benutzer Identität zusätzlich Attribute hinzuzufügen.
Dafür können HTTP-Header nach folgenden Muster gesendet werden:
X-Identity-Property-{{key}}: {{value}}
Zum Beispiel erzeugen folgende Header:
X-Identity-Property-mail: user@example.com
X-Identity-Property-color: light%20blue
diese Attribute:
"mail": "user@example.com"
"color": "light blue"
Hinweis: Der {{value}} muss HTML Form Encodiert sein.
Diese Attribute werden intern mit der Benutzer Identität (Identity Property) verknüpft und können dann in anderen Services verwendet werden.