Understanding and Using Security Guide marklogic pdf download

Permissions set on a document define access to capabilities read , insert , update , and execute for that document. Each permission consists of a capability and a role. This section describes how to set permissions on a document. It includes the following subsections:. Document permissions pair a role with a capability to perform some action on a document. You can add multiple permissions to a document. If a user is part of a role either directly or through inheriting the role specified as part of a document permission, then the user has that capability for the given document.

Each permission associates a role with one of the following capabilities:. The read capability provides the authority to see the content in the document. Being able to see the content does not allow you to modify the document. The update capability provides the authority to modify content in the document or delete the document.

However, update does not provide the authority to read the document. Reading the document requires the read capability. Users with update capability, but not read capability, can call the xdmp:document-delete and xdmp:document-insert functions successfully. However, node update functions, such as xdmp:node-replace , xdmp:node-delete , and xdmp:node-insert-after , cannot be called successfully.

Node update functions require a node from the document as a parameter. If a user cannot read the document, he cannot access the node in the document and supply it as a parameter.

There is a way to get around the issue with node update functions. The update capability provides the authority to change the permissions on a document. Therefore, you can use the xdmp:document-add-permissions function to add a new permission to the document with read capability for a given role.

A user withboth read and update capabilities can call node update functions succesfully. The insert capability provides a subset of the update capability. The insert capability provides the authority to add new content to the document. The insert capability by itself does not allow a user to change existing content or remove an existing document for example, calls to xdmp:document-insert and xdmp:document-delete on an existing document fail.

Furthermore, you need read capability on the document to perform actions that use any of the node insert functions xdmp:node-insert-before , xdmp:node-insert-after , xdmp:node-insert-child , as explained above in the description for update. Therefore, a permission with an insert capability must be paired with a permission with a read capability to be useful.

The execute capability provides the authority to execute application code contained in that document, if the document is stored in a database which is configured as a modules database. Users without permissions for the execute capability on a stored module, are not able to execute that module. When you create documents in a database, you must think about setting permissions on the document. If a document has no permission set on it, no one, other than users with the admin role, can read, update, insert, or delete it.

For examples of setting permissions on documents, see Example--Using Permissions. You can also secure membership in collections by assigning permissions to collections. To assign permissions to collections, you must use the Admin Interface or the security. You cannot assign permissions to collections implicitly with default permissions.

For more information about permissions on collections, see Collections and Security in the Search Developer's Guide.

Permissions assigned to documents pair a role with a capability, therefore roles are central to document permissions. Users derive authorization to perform actions from their roles. You configure users in the Admin Interface, where you assign a user a name, a password, a set of roles, and a set of default permissions. To see the security attributes associated with a given user, click on the User:username link in the Admin Interface screen for the given user.

For details on configuring users in the Admin Interface, see the 'Security Administration' chapter in the Administrator's Guide. During the initial installation of MarkLogic Server, two users are created. One of the users is an authorized administrator who has the admin role. During the installation, you are prompted to specify the username and password for this user.

The other user is a user named nobody , which is created with no roles assigned and is given a password which is randomly generated. This section describes the authentication schemes and includes the following parts:.

Basic authentication is the typical authentication scheme for web applications. When a user accesses an application page, she is prompted for a username and password. In basic mode, the password is obfuscated but not encrypted.

Digest authentication works the same way as basic, but offers encryption of passwords sent over the network. If you change an App Server from basic to digest authentication, it invalidates all passwords in the security database. Following the arrows pointing into Role2 and Role3 , you can see that the user possesses Priv1 and Priv2 based on the privileges assigned to these roles and insert and read capabilities based on the permissions applied to Document1.

Because User1 possesses Priv1 based on role inheritance , User1 is able to execute code protected with a xdmp:security-assert "Priv1", "execute" call; users who do not have the Priv1 privilege can not execute such code. MarkLogic Server has a special role named admin. The admin role has full authority to do everything in MarkLogic Server, regardless of the permissions or privileges set. In general, the admin role is only for administrative activities and should not be used to load data and run applications.

Use extreme caution when assigning users the admin role, because it gives them the authority to perform any activity in MarkLogic, included adding or deleting users, adding or deleting documents, changing passwords, and so on. MarkLogic Server also has a built-in role named security. Users who are part of the security role have execute privileges to perform security-related tasks on the system using the functions in the security. The security role does not have access to the Admin Interface.

To access the Admin Interface, a user must have the admin role. The security role provides the privileges to execute functions in the security. Consider a simple scenario with two roles - engineering and sales. The engineering role is responsible for making widgets and has privileges needed to perform activities related to making widgets.

The sales role is responsible for selling widgets and has privileges to perform activities related to selling widgets. To begin, create two roles in MarkLogic Server named engineering and sales respectively. The engineering role needs to be able to make widgets.

Names for execute privileges are used only as display identifiers in the Admin Interface. Ron is an engineer in your company so you create a user for Ron and assign the engineering role to the newly created user. Emily is an account representative so you create a user for Emily and assign her the sales role. In your XQuery code, use the xdmp:security-assert function to ensure that only engineers make widgets and only account representatives sell widgets if you are using JavaScript, you can similary call xdmp.

For example:. If Emily attempts to execute the make-widget function, the xdmp:security-assert function call throws an exception. If the exception is not caught, the transaction that called this function is rolled back.

Some functions are common to several protected actions. You can protect such a function with a single xdmp:security-assert call by providing the appropriate action URIs in a list.