Securing MarkLogic Server

If there is a set of permission requirements that meets the needs of most application scenarios, MarkLogic Server recommends creating the appropriate default permission settings at the role or user level. This avoids having to explicitly create and set document permissions each time you call xdmp:document-load() or xdmp:document-insert().

Default permission settings that apply to a user, either through a role or through the user definition, are important if you are loading documents using a WebDAV client. When you drag and drop files into a WebDAV folder, the permissions are automatically set based on the default permissions of the user logged into the WebDAV client. For more information about WebDAV servers, see WebDAV Servers in Administrating MarkLogic Server.

The following screenshot shows a portion of the Admin Interface for the engineering role. It shows read and insert capabilities being added to the engineering role’s default permissions.

A user’s set of default permissions is additive; it is the aggregate of the default permissions for all of the user’s role(s) as well as for the user himself. Below is another screenshot of a portion of a User configuration screen for Ron. It shows read and update capabilities being added to the engineering-manager role.

You can also use a hybrid of the two methods described above. Assume that read and insert capabilities for the engineering role are specified as default permissions for the engineering role as shown in the first screenshot. However, update and read capabilities are not specified for the engineering-manager at the user or engineering role level.

Further assume that the following code snippet is executed by Ron. It achieves the desired objective of giving the engineering-manager role read, update, and node-update capabilities on the document, and the engineering role read and insert capabilities.

...
xdmp:document-insert("/widget.com/engineering/features/2017-q1.xml", 
       <new-features>
         <feature> 
           <name>blue whistle</name>
           <assigned-to>Ron</assigned-to>
           ...
          </feature>
         ...
       </new-features>,
        (xdmp:default-permissions(),
         xdmp:permission("engineering-manager", "read")
         xdmp:permission("engineering-manager", "update"))
         xdmp:permission("engineering-manager", "node-update"))
...

xdmp:default-permissions() returns Ron’s default permissions (from the role level in this example) of read and insert capabilities for the engineering role. The read, update, and node-update capabilities for the engineering-manager role are then added explicitly as function parameters.

Suppose that Ian, of the engineering-manager role, decides to give users of the sales role read permission on the document. (He wisely withholds update or insert capability or there will surely be an explosion of features!) The code snippet below shows how to add permissions to a document after it has been created.

...
xdmp:document-add-permissions(
  "/widget.com/engineering/features/2017-q1.xml", 
  xdmp:permission("sales", "read"))
...

The update capability is needed to add permissions to a document, and the node-update capability is needed to update a portion of a document (or node). Therefore, the code snippet only succeeds if it is executed by Ian--or by another user of the engineering-manager role. This prevents Ron from giving Emily, his buddy in sales, insert capability on the document.

But what if the Emily is now the person in sales assigned to the project? Ian has the node-update capability, so he can call xdmp:node-replace() and xdmp:node-delete() to modify nodes in a document. Ian changes the assigned-to element in the document using xdmp:node-replace() .

...
xdmp:node-replace(
  fn:doc("/widget.com/engineering/features/2017-q1.xml")/new-features/feature/assigned-to, 
  <assigned-to>Emily</assigned-to>
)

Changing default permissions for a role or a user does not affect the permissions associated with existing documents. To change permissions on existing documents, you need to use the permission update functions. See the documentation for the MarkLogic Server Built-In Functions in the XQuery and XSLT Functions by Category reference for more details.