The following roles are pre-defined in every installation of MarkLogic Server. To give a user execute privileges listed for each pre-defined role, you may add the execute privileges individually to an existing role for the user, or add the pre-defined role to the user's set of roles.
The following are the pre-built roles in MarkLogic Server:
The admin
role is given all privileges and permissions to perform any action in the system. There are no default permissions associated with the admin
role. Users with the admin
role are considered authorized administrators; they are trusted personnel and are assumed to be non-hostile, appropriately trained, and follow proper administrative procedures.
The admin-builtins
role has the execute privileges to call the admin built-in functions. The execute privileges given to the admin-builtins role are:
There are no default permissions associated with the admin-builtins
role.
The admin-configuration-delete
role enables administrator users to delete configuration information.
The admin-configuration-read
role enables administrator users to read configuration information.
The admin-configuration-write
role enables administrator users to write configuration information.
The admin-default
role enables administrator users to evaluate administration default expressions.
The admin-default-internal
role enables administrator users to invoke administration default expressions.
The admin-module-read-internal
role is used internally by the Admin Library Module. Do not assign this role to any user. For details, see Scripting Administrative Tasks in MarkLogic Server in the Scripting Administrative Tasks Guide.
The admin-module-read-internal
role is used internally by the Admin Library Module for reading. Do not assign this role to any user. For details, see Scripting Administrative Tasks in MarkLogic Server in the Scripting Administrative Tasks Guide.
The admin-module-read-internal
role is used internally by the Admin Library Module for invoking functions with granular privileges. Do not assign this role to any user. For details, see Scripting Administrative Tasks in MarkLogic Server in the Scripting Administrative Tasks Guide.
The admin-transform
role enables administrator users to evaluate transformations within the Admin API.
The admin-ui-user
role enables users to have a read-only view of the Admin UI, without providing access to data, to security configuration, or write access to server configuration.
The alert-admin
role is used for administrators of an alerting application. For details, see the Creating Alerting Applications chapter of the Search Developer's Guide.
The alert-execution
role is used internally by the Alerting API to amp privileges in a protected way. Do not give this role to any individual users. For details, see the Creating Alerting Applications chapter of the Search Developer's Guide.
The alert-internal
role is used internally by the Alerting API to amp privileges in a protected way. You should not give this role to any individual users. For details, see the Creating Alerting Applications chapter of the Search Developer's Guide.
The alert-user
role is used by users of an alerting application. For details, see the Creating Alerting Applications chapter of the Search Developer's Guide.
The app-builder
role provides the privileges needed to run Application Builder. Application Builder is no longer a part of MarkLogic. This role exists only for backward compatibility.
Application Builder is no longer a part of MarkLogic. This role exists only for backward compatibility.
The app-user
role is a minimally privileged role that is needed to run any application that Application Builder generates. Application Builder is no longer a part of MarkLogic. This role exists only for backward compatibility.
The application-plugin-registrar
role is used in the plugin API, and has the following execute privileges:
The appservices-internal
role is used by Application Services to amp certain functions that Application Services performs. You should not explicitly grant the appservices-internal
role to any user; it is only for internal use by Application Services.
The cpf-restart
role is used by CPF to control access to the CPF restart trigger. The CPF restart user should have the cpf-restart
role, as well as all of the permissions and privileges that normal users have on the documents.
The custom-dictionary-admin
role is to perform adminstative functions (for writing dictionaries in the configuration) in the custom dictionary API.
The custom-dictionary-user
role is to perform user functions (for reading dictionaries in the configuration) in the custom dictionary API.
The custom-language-admin-read
role enables a user to read custom language configuration. That is, to use functions such as clang:language-config-read.
The custom-language-admin-write
role enables a user to modify custom language configuration. That is, to use functions such as clang:language-config-write and clang-language-config-delete
. These operations change the cluster configuration file and cause a cluster-wide restart when used.
The dls-admin
role is designed to give administrators of Library Services applications all of the privileges that are needed to use the Library Services API. It has the needed privileges to perform operations such as inserting retention policies and breaking checkouts, so only trusted users (users who are assumed to be non-hostile, appropriately trained, and follow proper administrative procedures) should be granted the dls-admin
role. Assign the dls-admin
role to administrators of your Library Services application.
For details, see the Library Services Applications chapter in the Application Developer's Guide.
The dls-internal
role is a role that is used internally by the Library Services API, but you should not explicitly grant it to any user or role. This role is used to amp special privileges within the context of certain functions of the Library Services API. Assigning this role to users would give them privileges on the system that you typically do not want them to have; do not assign this role to any users.
For details, see the Library Services Applications chapter in the Application Developer's Guide.
The dls-user
role is a minimally privileged role. It is used in the Library Services API to allow regular users of the Library Services application (as opposed to dls-admin
users) to be able to execute code in the Library Services API. It allows users, with document update permission, to manage, checkout, and checkin managed documents.
The dls-user
role only has privileges that are needed to run the Library Services API; it does not provide execute privileges to any functions outside the scope of the Library Services API. The Library Services API uses the dls-user
role as a mechanism to amp more privileged operations in a controlled way. It is therefore reasonably safe to assign this role to any user whom you trust to use your Library Services application. Assign the dls-user
role to all users of your Library Services application.
For details, see the Library Services Applications chapter in the Application Developer's Guide.
The domain-management
role has the privileges to create and modify content processing domains. The domain-management role has no execute privileges associated with it, but it has the following default permissions:
Role | Capability |
---|---|
domain-management | Read |
domain-management | Update |
The filesystem-access
role has the privileges to access the file system. The execute privileges given to the filesystem-access
role are:
There are no default permissions associated with the filesystem-access role.
The flexrep-internal
role is used by Flexible Replication to amp certain functions that Flexible Replication performs. You should not explicitly grant the flexrep-internal
role to any user; it is only for internal use by Flexible Replication.
The flexrep-user
role user is required to access the Replica App Server when configured for push replication and the Master App Server when configured for pull replication. The replication user must be given the flexrep-user
role and have the privileges necessary to update the domain content.
The hadoop-internal role
is for internal use only. Do not assign this role to any users. This role is used to amp special privileges within the context of certain functions of the Hadoop MapReduce Connector. Assigning this role to users would give them privileges on the system that you typically do not want them to have.
The hadoop-user-all
role combines the privileges of hadoop-user-read
and hadoop-user-write
.
The hadoop-user-read
role allows use of MarkLogic Server as an input source for a MapReduce job. This role does not grant any other privileges, so the mapreduce.marklogic.input.user
may still require additional privileges to read content from the target database. The hadoop-user-read
role has the following execute privileges:
The hadoop-user-write
role allows use of MarkLogic Server as an output destination for a MapReduce job. This role does not grant any other privileges, so the mapreduce.marklogic.output.user
may still require additional privileges to insert or update content in the target database. The hadoop-user-write
role has the following execute privileges:
Information Studio is no longer a part of MarkLogic. This role exists only for backward compatibility.
The infostudio-admin-user
role provides the privileges needed to handle CPF restart and resume unfinished Information Studio tasks in the event of an unexpected shutdown and restart of MarkLogic Server. When MarkLogic Server is restarted, long-running collectors resume loading documents in the database. In this situation, the original user that started the collector is unknown, so the purpose of the infostudio-admin user
is to resume control of the collector.
Information Studio is no longer a part of MarkLogic. This role exists only for backward compatibility.
The infostudio-user
role is used by Information Studio to amp certain functions that Information Studio performs. You should not explicitly grant the infostudio-internal
role to any user; it is only for internal use by Information Studio.
Information Studio is no longer a part of MarkLogic. This role exists only for backward compatibility.
The infostudio-user
role is a minimally privileged role that is needed to use Information Studio. You must grant this role to all users who are allowed to access Information Studio.
The infostudio-user
role has the following execute privileges:
The manage
role has the execute privilege http://marklogic.com/xdmp/privileges/manage
to run the Management API. For example, non-admin users can use manage
role plus create-data-role
or create-data-user
granular privileges to manage roles and create data users.
Name | Action URI |
---|---|
manage | http://marklogic.com/xdmp/privileges/manage |
There are no default permissions associated with the manage
role.
The manage-admin
role has the privileges related to accessing the management API and the tiered storage API for operations that change the configuration. The execute privileges given to the manage-admin
role are:
There are no default permissions associated with the manage-admin
role.
The manage-admin-internal
role is used to amp certain functions used by the Configuration Manager and the Management API. You should not explicitly grant the manage-admin-internal
role to any user; it is only for internal use.
The manage-internal
role is used to amp certain functions used by the Configuration Manager. You should not explicitly grant the manage-internal
role to any user; it is only for internal use.
The manage-user
role has the privileges related to accessing the Configuration Manager. The execute privileges given to the manage-user
role are:
Name | Action URI |
---|---|
manage | http://marklogic.com/xdmp/privileges/manage |
There are no default permissions associated with the manage-user
role.
The merge
role has the privileges related to forest merging. The execute privileges given to the merge
role are:
Name | Action URI |
---|---|
xdmp:merge | http://marklogic.com/xdmp/privileges/xdmp-merge |
xdmp:merging | http://marklogic.com/xdmp/privileges/xdmp-merging |
There are no default permissions associated with the merge
role.
The network-access role has the privileges to run the xdmp:http-*
functions (xdmp:http-get, xdmp:http-post, and so on). The execute privileges given to the network-access
role are:
The pipeline-execution
role is used in the XQuery code to allow any user (who can write a document to the domain) to execute code in the pipeline.
For details, see the Content Processing Framework Guide guide.
The pipeline-management
role has the privileges to create and modify content processing pipelines. The pipeline-management
role has no execute privileges associated with it, but it has the following default permissions:
Role | Capability |
---|---|
pipeline-management | Read |
pipeline-management | Update |
The pki
role has the privileges to use the PKI Library functions. For details, see Configuring SSL on App Servers in the Security Guide.
The plugin-user
role is used to amp certain functions associated with plugins. You should not explicitly grant the plugin-internal
role to any user; it is only for internal use by the plugin API.
The qconsole-internal
role is used by Query Console to amp certain functions that Query Console performs. You should not explicitly grant the qconsole-internal
role to any user; it is only for internal use by Query Console.
The qconsole-user
role is a minimally privileged role that is needed to use Query Console. You must grant this role to all users who are allowed to use Query Console.
The qconsole-user
role has the following execute privileges:
The rest-admin
role has the rest-writer
and manage-user
roles and allows those granted the role full access to read and write via the REST API.
The rest-admin-internal
role is used internally by the REST Library. You should not explicitly grant it to any user or role.
The rest-extension-user
role enables access to resource service extension methods. .
The rest-internal
role is used internally by the REST Library. You should not explicitly grant it to any user or role.
The rest-reader
role enables read operations through the MarkLogic REST API, such as retrieving documents and metadata.
The rest-reader-internal
role is used internally by the REST Library. You should not explicitly grant it to any user or role.
The rest-writer
role enables write operations through the MarkLogic REST API, such as creating documents, metadata, or configuration information.
The rest-writer-internal
role is used internally by the REST Library. You should not explicitly grant it to any user or role.
The search-internal
role is a role that is used internally by the search API. You should not explicitly grant it to any user or role.
The security
role has the privileges needed to perform security functions. The execute privileges given to the security
role are:
Default permissions for the security
role are:
Role | Capability |
---|---|
security | Read |
security | Insert |
security | Update |
The temporal-internal
role is an internal role. Do not assign this role to any user.
The trigger-management
role has the privileges to create and modify triggers. The trigger-management
role has no execute privileges associated with it. This role has the following default permissions:
Role | Capability |
---|---|
trigger-management | Read |
trigger-management | Update |
The view-admin-internal
role is used internally by the MarkLogic Server. Do not explicitly grant it to any user or role.
The welcome-internal
role is a role that used to be used internally by the MarkLogic Server Welcome Page (now removed). Do not explicitly grant it to any user or role.
The xa
user role allows creation and management of one's own XA transaction branches
in MarkLogic Server. The xa
role is required to participate in XA transactions. For details, see Participating in XA Transactions in the XCC Developer's Guide. The xa
role has the following execute privileges:
The xa-admin
role allows creation and manage of any user's XA transaction branches in
MarkLogic Server. The xa-admin role is intended primarily for Administrators who need to complete or forget XA transactions. The xa-admin
role has the following execute privileges:
The xinclude role
provides the privileges to run the XInclude code used in the XInclude CPF application. For details, see Reusing Content With Modular Document Applications in the Application Developer's Guide.