Roles
Roles are named sets of permissions that encapsulate the permissions needed for different kinds of users. Permissions grant users access to subsets of Managed Fusion functionality. A role can specify UI permissions, API permissions, or both:
-
UI permissions grant users access to parts of the Managed Fusion UI.
-
API permissions grant users access to specific API commands for specific REST API endpoints.
See Permissions for information about how permissions supplied by multiple roles and by user definitions combine.
Users who can create or modify code obtain access to the broader Managed Fusion environment. This access can be used to create intentional or unintentional damage to Managed Fusion. |
Roles and environments
The roles that Managed Fusion clients have depend on the type of environment.
Default roles
At initial startup, Managed Fusion creates a set of default roles for common types of users.
admin
The admin role is the equivalent to the Unix root
or superuser.
It allows full access to all Managed Fusion services:
GET,POST,PUT,DELETE,PATCH,HEAD:/**
developer
The developer role has all the read/write permissions required for building and running applications. This role cannot add users; user management is handled by Lucidworks.
The developer role is updated for Managed Fusion 5.10 to exclude permissions for creating, editing, and deleting Spark jobs, JavaScript stages in querying and indexing pipelines, and custom index and query stages. The new roles including these permissions are created when upgrading to Managed Fusion 5.10, but the existing developer role is not updated in order to prevent unexpected changes. |
GET,POST,PUT:/system/**
GET,POST,PUT,DELETE,HEAD:/stopwords/**
GET,POST,PUT:/usage/**
GET:/features/**
GET,POST,PUT,DELETE,HEAD:/blobs/**
GET,POST,PUT,DELETE,HEAD:/scheduler/**
GET,POST,PUT,DELETE,HEAD:/experiments
GET:/introspect/**
PUT:/usage/**
GET,POST,PUT,DELETE,HEAD:/index-stages/**
GET,POST,PUT,DELETE,HEAD:/messaging/**
GET,POST,PUT,DELETE,HEAD:/catalog
GET,POST,PUT,DELETE,HEAD:/parsers/**
GET,POST,PUT:/appkit/**
GET,POST,PUT,DELETE,HEAD:/index-profiles/**
GET,POST,PUT:/recommend/**
GET,POST,PUT,DELETE,HEAD:/history/**
GET,POST,PUT,DELETE,HEAD:/apps/**
GET,POST,PUT,DELETE,HEAD:/solr/**
GET,POST:/query/**
GET,POST,PUT:/signals/**
GET,POST,PUT:/searchLogs/**
GET,POST,PUT,DELETE,HEAD:/query-pipelines/**
GET,POST,PUT:/configurations/**
GET:/suggestions/**
GET,POST,PUT,DELETE,HEAD:/searchCluster/**
GET,POST,PUT,DELETE,HEAD:/index-pipelines/**
GET:/license
GET,POST,PUT,DELETE,HEAD:/spark/**
GET,POST,PUT,DELETE,HEAD:/query-stages/**
GET,POST,PUT,DELETE,HEAD:/prefs/apps/search/*
GET:/nodes/**
GET,POST,PUT,DELETE,HEAD:/solrAdmin/**
GET,POST,PUT:/synonyms/**
GET,POST,PUT,DELETE,HEAD:/jobs/**
GET,POST,PUT,DELETE,HEAD,OPTIONS:/collections/**
GET,POST,PUT,DELETE,HEAD:/connectors/**
GET,POST,PUT,DELETE,HEAD:/groups/**
GET,POST,PUT,DELETE,HEAD:/query-profiles/**
GET,POST,PUT:/templates/**
GET,POST,PUT,DELETE,HEAD:/tasks/**
GET,POST,PUT,DELETE,HEAD:/links/**
PATCH:/users/{id}:id=#ID
GET,POST,PUT:/registration/**
POST:/index/**
GET,POST,PUT:/objects/**
GET,POST,PUT:/templates/**
The permission PATCH:/users/{id}:id=#ID uses the variable value #ID as a placeholder for the currently logged-in user ID. It is included so the Managed Fusion UI "change password" feature is available to native realm users.
|
readonly
The readonly role can view everything in Fusion but cannot modify configurations. Managed Fusion customers must make changes in the appropriate stage environment, after which Lucidworks will promote the change to production.
PUT,DELETE:/apps/*/blobs/prefs-*._lw_tmp_*
PUT,DELETE:/prefs/apps/search/*._lw*_tmp_*
PUT,DELETE:/apps/*/query-pipelines/_lw*_tmp_*
POST:/prefs/apps/search
PUT,DELETE:/apps/*/index-pipelines/_lw*_tmp_*
POST:/apps/*/query-pipelines
POST:/query-pipelines/_system/collections/*/select
POST:/apps/*/parsers
POST:/apps/*/index-pipelines
PUT:/usage/counters/*
GET:/**
PUT,DELETE:/apps/*/parsers/_lw*_tmp_*
POST,GET,PUT:/signals/**
rules
The rules role provides query rewriting API access to all Managed Fusion apps.
GET:/apps/*/query-profiles/**
GET,POST,PUT,PATCH,DELETE,HEAD:/apps/*/query-rewrite/**
GET:/solr/**
GET:/query/**
GET:/collections/**
GET:/apps/**
search
The search role has read-only query and write-only signal API access to the Managed Fusion "default" collection. These permissions are required for search applications, for example, for App Studio.
POST:/apps/*/signals/**
GET,POST:/query/**
POST:/signals/**
PATCH:/users/{id}:id=#ID
GET,POST:/apps/*/query/**
The permission PATCH:/users/{id}:id=#ID uses the variable value #ID as a placeholder for the currently logged-in user ID. It is included so the Managed Fusion UI "change password" feature is available to native realm users.
|
webapps-role
The webapps role can list and download Managed Fusion apps.
GET,HEAD:/webapps/**
GET,HEAD:/license
Role information
Managed Fusion stores role information in Apache ZooKeeper. Each role in a ZooKeeper entry contains the following:
-
id
– ID string, created by Managed Fusion -
name
– Role name string -
desc
– Text description; optional -
permissions
– A list of Managed Fusion permission specifications -
ui-permisions
– A list of names of Managed Fusion UI components -
created-at
– Timestamp; created by Managed Fusion -
updated-at
– Timestamp for last edit; created by Managed Fusion
Manage roles
Only users with admin privileges can manage roles. In Managed Fusion environments, Lucidworks is responsible for managing roles.
Assign job permissions
The colon character : is a special character used in the permissions engine, so you must use an asterisk * in the command.
|
To assign permissions for a specific job, enter the following command, where you must enter the specific job in the <JOB_NAME>
field:
POST:/apps/*/jobs/task*<JOB_NAME>/actions
Assign job permissions in the UI
The command to assign permissions for a specific job in the UI is an exact call, so you must specify the <JOB_NAME>
.
For example, if the job name is testing-call
, two example commands are:
POST:/apps/<APP_NAME>/jobs/task:testing-call/actions
or
POST:/apps/*/jobs/task:testing-call/actions
Assign permissions in the API
The command to assign permissions to a job using an API does not require you to specify the <APP_NAME>
.
Two example commands are:
POST:/jobs/**
or
POST:/jobs/task*<JOB_NAME>/actions