Berechtigungen

Ein umfangreiches Feature ist die Filterung der Suchergebnisse basierend auf den Rechten des angemeldeten Nutzers. Meldet sich ein Nutzer am smart.finder an, so erhält dieser mit erfolgreicher Anmeldung bestimmte Rechte am System (sog. Permissions).

Für jeden Core des smart.finder (also jeden separaten Index) kann festgelegt werden, welche Dokumente ein Nutzer mit einem bestimmten Recht sehen darf. Darüber hinaus können zusätzlich die Felder der einzelnen Dokumente gefiltert werden. Somit kann ein Nutzer ein Dokument zwar im Rahmen des Suchergebnisses sehen, aber eben nur bestimmte Felder.

Folgendes Szenario erläutert diesen Ablauf:

Ein Nutzer hat sich erfolgreich am smart.finder angemeldet und besitzt, u. a., die Permission VIEW_A. Nutzer mit dieser Permission sollen aber nur Ergebnisse vom Layer 2210 sehen dürfen. Des weiteren sind die Dokumente für Nutzer mit dieser Permission beschränkt auf die Felder id, spatial, layer und title. Der Nutzer führt eine Suche gegen den Index core0 aus. Die Permissions des Nutzers sind in der aktuellen Session bekannt und können somit serverseitig ausgewertet werden. Im Index existieren zwei potenzielle Dokumente mit den IDs 1234_A und 1234_B, die der Suche des Nutzers entsprechen.
Im zweiten Schritt wird überprüft, ob es für den Index core0 eine Filterregel gibt, die die Permission VIEW_A betrifft. Diese Filterregel setzt die o.g. Einschränkung auf dem internen Suchergebnis durch: alle Dokumente filtern, die nicht vom Layer 2210 stammen. Die Einschränkung auf die Felder wird bereits bei der initialen Suche berücksichtigt.
Im Ergebnis wird nach der serverseitigen Durchsetzung des Filters nur das Dokument mit der ID 1234_A Teil des Suchergebnisses sein. Zudem ist die Sicht auf die Felder id, spatial, layer und title beschränkt.
Das final gefilterte Dokument wird als Suchergebnis zurückgegeben.

Konfiguration der Permissions

Ein angemeldeter Nutzer wird vom verwendeten Identity Provider mit einer oder mehreren Rollen versehen. Diese Rollen werden im smart.finder für die feingranulare Zuweisung von Permissions verwendet. Diese Zuweisung erfolgt in der Datei /smartfinder-search/WEB-INF/classes/permissions.json:

{
  "anonymous": {
    "permissions": [
      "VIEW_DETAIL",
      "VIEW_SEARCH",
      "LOGIN",
      "LOGOFF"
    ]
  },
  "editor": {
    "inherits-from": "anonymous",
    "permissions": [
      "EDIT"
    ]
  },
  "solrAdmin": {
    "inherits-from": "anonymous",
    "permissions": [
      "ADMIN"
    ]
  }
}

Im o.g. Beispiel erhält jeder Nutzer die Permissions VIEW_DETAIL, VIEW_SEARCH, LOGIN und LOGOFF. Die Rolle anonymous ist eine systeminterner Platzhalter für nicht angemeldete Nutzer.

Die Rolle editor erweitert (inherits-from) diese Liste um die Permission EDIT. Ein Nutzer mit der Rolle editor erhält somit die Permissions VIEW_DETAIL, VIEW_SEARCH, LOGIN, LOGOFF und EDIT.

Konfiguration der Filterregeln

Die Einschränkung der Sicht auf den Index erfolgt im nächsten Schritt durch die Definition von Filter Queries und Field Lists.

Filter Queries und Field Lists sind funktionale Bestandteile von Apache Solr. Details dazu finden Sie in der offiziellen Solr-Dokumentation unter Filter Queries und Field Lists

Die Filter werden unter /smartfinder-search/WEB-INF/templates/filter in der Server-Webapp konfiguriert und können explizit für jeden Core einzeln festgelegt werden. Dies erfolgt über den Dateinamen, z.B. core0.ftl für den Core core0.

Die *.ftl Dateien werden im Freemarker Format beschrieben. Durch die Verwendung dieser Template Engine lassen sich zusätzlich Laufzeitinformationen nutzen, um die Filter zu beschreiben (User-Objekte, Requests, etc.).

Eine simple Konfiguration sieht z.B. wie folgt aus:

{
    "ANONYMOUS": {
        "prio": 10,
        "fq": "category:public",
        "fl": "id,title"
    },
    "EDIT": {
        "prio": 100,
        "fq": "category:(public OR protected)",
        "fl": "id,title,category,a,b"
    },
    "ADMIN": {
        "prio": 101,
        "fq": "*:*"
    }
}

Mit folgenden Parametern:

prio: Legt fest, welches Mapping im Falle von mehreren Permissions gewinnt. Die exakte Zahl ist dabei nicht relevant, sondern nur die Reihenfolge.
fq: Filter Query für die genannte Permission, die server-seitig an jede Query eines Nutzers mit dieser Permission angehangen wird.
fl: Komma separierte Liste von Feldern für diese Permission. Diese Field List definiert, welche Felder eines Dokumentes für den Nutzer sichtbar sind.

Erläuterung des Beispiels: hat ein Nutzer die Permissions EDIT und ADMIN, gewinnt im hier dargestellten Fall die Permission ADMIN und die Filter Query : wird ergänzt. Somit können Hierarchien in den Permissions abgebildet werden.

Ein etwas umfangreicheres Beispiel zeigt im Folgenden, wie Objekte dynamisch abgefragt werden können, um die Filter zu generieren:

<#assign group = "${user.groups[0]}">
<#assign authenticatedQuery = '_v_:public OR local:false OR _o_:"${user.username}"'>
{
   "ANONYMOUS" : {
       "prio": 1,
       "fq": "_v_:public OR local:false",
        "fl",
   },
   "AUTHENTICATED" : {
       "prio": 1,
       "fq": "${authenticatedQuery?json_string}"
   },
   "ADMIN": {
       "prio": 200,
       "fq": "*:*"
   },
   "GROUP_ADMIN": {
       "prio": 150,
       "fq": "${authenticatedQuery?json_string} OR (_v_:protected AND _g_:\"${group}\") OR (_v_:private AND _g_:\"${group}\")"
   },
   "VIEW_GROUP_MD" : {
       "prio": 100,
       "fq": "${authenticatedQuery?json_string} OR (_v_:protected AND _g_:\"${group}\")"
   }
}

In diesem Beispiel wird die Permission AUTHENTICATED eingeführt, die für alle angemeldeten Nutzer gilt. Die Filter Query wird dynamisch generiert und enthält die Information, ob ein Dokument vom Nutzer selbst erstellt wurde. Die Permission GROUP_ADMIN erweitert die Filter Query um die Gruppenzugehörigkeit des Nutzers. Die Permission VIEW_GROUP_MD erlaubt den Zugriff auf Dokumente, die von der Gruppe des Nutzers erstellt wurden.