Product Selector

Fusion 5.9
    Fusion 5.9

    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/**

    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