Permissions

An extensive feature is the filtering of search results based on the rights of the logged-in user. If a user logs in to smart.finder, they receive certain rights to the system (so-called permissions) once they have successfully logged in.

For each core of the smart.finder (i.e. each separate index), you can specify which documents a user with a specific permission is authorised to view. The fields of the individual documents can also be filtered. This means that a user can see a document as part of the search result, but only certain fields.

The following scenario explains this process:

a user has successfully logged in to smart.finder and has, among other things, the permission VIEW_A. However, users with this permission should only be able to see results from layer 2210. Furthermore, the documents for users with this permission are restricted to the fields id, spatial, layer and title. The user performs a search against the index core0. The user’s permissions are known in the current session and can therefore be analysed on the server side. There are two potential documents in the index with the IDs 1234_A and 1234_B, which correspond to the user’s search.
in the second step, the system checks whether there is a filter rule for the index core0 that affects the permission VIEW_A. This filter rule enforces the above-mentioned restriction on the internal search result: filter all documents that do not originate from layer 2210. The restriction to the fields is already taken into account during the initial search.
as a result, only the document with the ID 1234_A will be part of the search result after the server-side enforcement of the filter. In addition, the view is restricted to the fields id, spatial, layer and title.
the final filtered document is returned as the search result.

Configuration of permissions

A registered user is assigned one or more roles by the identity provider used. These roles are used in smart.finder for the fine-grained assignment of permissions. This assignment takes place in the file /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"
    ]
  }
}

In the above example, each user receives the permissions VIEW_DETAIL, VIEW_SEARCH, LOGIN and LOGOFF. The anonymous role is an internal placeholder for users who are not logged in.

The role editor extends (inherits-from) this list with the permission EDIT. A user with the role editor thus receives the permissions VIEW_DETAIL, VIEW_SEARCH, LOGIN, LOGOFF and EDIT.

Configuration of the filter rules

The next step is to restrict the view of the index by defining Filter Queries and Field Lists.

Filter Queries and Field Lists are functional components of Apache Solr. Details can be found in the official Solr documentation at Filter Queries and Field Lists

The filters are configured under /smartfinder-search/WEB-INF/templates/filter in the server web app and can be explicitly defined individually for each core. This is done via the file name, e.g. core0.ftl for the core core0.

The *.ftl files are described in Freemarker Format . By using this template engine, additional runtime information can be used to describe the filters (user objects, requests, etc.).

A simple configuration looks like this, for example:

{
    "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": "*:*"
    }
}

With the following parameters:

prio: Determines which mapping wins in the event of multiple permissions. The exact number is not relevant, only the order.
fq: Filter query for the specified permission, which is appended on the server side to every query from a user with this permission.
fl: Comma-separated list of fields for this permission. This field list defines which fields of a document are visible to the user.

Explanation of the example: if a user has the permissions EDIT and ADMIN, the permission ADMIN wins in the case shown here and the filter query : is added. Hierarchies can thus be mapped in the permissions.

A somewhat more extensive example shows below how objects can be queried dynamically to generate the filters:

<#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 this example, the permission AUTHENTICATED is introduced, which applies to all logged-in users. The filter query is generated dynamically and contains the information as to whether a document was created by the user. The GROUP_ADMIN permission extends the filter query to include the user’s group membership. The VIEW_GROUP_MD permission allows access to documents created by the user’s group.