Permissions

Permissions determine what a user can do in Fusion. There are two kinds of permissions:

  • UI permissions – Control which parts of the Fusion UI a user can access. These parts show up in menus and the user can view them. But the ability to use the functionality depends on API permissions. (The UI uses the API.)

  • API permissions – Control which requests a user can submit to which REST API endpoints.

Fusion uses permissions for authorization as follows:

  • UI permissions are positive (permission needs to be given) and additive (the user has the sum of all specified permissions. This is true of roles specified in a user definition, roles specified in a security realm, and roles determined dynamically based on groups in an LDAP authentication provider.

  • API permissions specified in roles are positive (permission needs to be given) and additive (the user has the sum of all specified permissions; that is, for a specific endpoint, the most permissive permissions are used). This is true of roles specified in a user definition, roles specified in a security realm, and roles determined dynamically based on groups in an LDAP authentication provider.

  • API permissions specified in the role(s) but not in the user definition are used.

  • If an API permission for a specific endpoint is specified in both one or more roles and in the user definition, then the permissions in the user definition are used, overriding the permissions in the role(s). Use permissions in user definitions to give specific users permissions that are less permissive than the permissions for their role(s). Alternatively, you could define less permissive roles.

Specify UI Permissions

Specify UI permissions in roles.

Specify API Permissions

A Fusion API permission denotes an allowed request to a Fusion REST API endpoint or endpoints. A permissions specification consists of:

  • HTTP request method or methods allowed. Multiple HTTP methods are separated by commas.

  • REST API services endpoint, which can contain wildcards or named variables. All calls to the REST API start with "api/apollo", followed by the service name and any methods and parameters. The permissions specification includes everything following "api/apollo". The endpoint can include wildcards.

Wildcards make it easy to grant broad access to Fusion services. The wildcard symbol '*' matches all possible values for a single path segment and two wildcards match all possible values for any number of path segments. Granting access to a subset of Fusion’s functionality requires a list of narrowly defined permissions.

A path segment can be a named variable enclosed in curly braces: {variable-name}. Variables are used when a wildcard would be too permissive and a single path segment too restrictive.

  • Optionally, the allowed values for any named variables in the endpoint. The variable specification component specifies the restricted value or values for all named variables in the path. Each specification consists of the variable name, followed by "=" (the equals sign), followed by one or more values which are separated by commas. If the endpoint specification has multiple variable, the semi-colon character ";" is used as the separator between parameter specifications.

Permissions specifications are coded up as a string using the colon character ":" as the separator between the permission elements.

Here are some examples of permissions specifications:

  • GET:/query-pipelines/*/collections/\*/select – Search access to any Fusion collection.

  • GET,PUT:/collections/Collection345/synonyms/*\* – Permission to edit synonyms for the collection named "Collection345"

  • GET:/collections/{id}:id=Collection345,Collection346 – Read access to collections named "Collection345" and "Collection346"

In ZooKeeper, both User and Roles entries contain a list of Permission specifications. A Permission entry has three attributes: "methods", "path", and "params".

Example Permissions Set

Wildcards make it easy to give wide access to Fusion services. The permissions for the admin user can be written in a single line:

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

To restrict access to a single collection and a single Fusion facility requires a set of narrowly defined permissions. For example, the following set of permissions allows a user to run Fusion’s analytics dashboards over a collection named "test":

  • GET:/solr/{id}/*:id=test– Read-only access to collection named "test"

  • GET:/solr/{id}/admin/luke:id=test– Dashboards require read-only access to Solr utility luke to compile collection metrics.

  • GET:/solr/system_banana/*– Read-only access to dashboards

  • GET:/collections/system_banana– Read-only access to the collection where dashboard definitions are stored

Read-only access to the dashboard definitions collection means that the user cannot save the configured dashboard back to Fusion.

The following JSON shows how Fusion stores this list of permissions in ZooKeeper:

"permissions":[
  {"params": {"id":["mdb1"]},
   "path":"/solr/{id}/*",
   "methods":["GET"]},
  {"params":{"id":["mdb1"]},
   "path":"/solr/{id}/admin/luke",
   "methods":["GET"]},
  {"path":"/solr/system_banana/*",
   "methods":["GET"]},
  {"path":"/collections/system_banana",
   "methods":["GET"]}
  ]