CODEWITHSUNDEEP
securitypermissionsmarklogicroles
Manish Joisar
Manish Joisar

Reputation: 1310

Role creation based on MarkLogic permissions

MarkLogic 9.0.8.2

We have developed API to get & set data in MarkLogic, All data are stored in xml format within MarkLogic

Now we want to expose this API endpoint to external users with below operations

So we want to create different user credentials based on permission like ReadOnly, ExecuteOnly.

What all Roles & Permissions we need to select to make sure they can perform what they are allowed to?

Upvotes: 0

Views: 203

Answers (1)

grtjn
grtjn

Reputation: 20414

Note upfront: permissions are about document access, privileges about function access. Execute permission in specific only applies to module access, not document access.

There are many ways to organize your security, but ground basics are usually fairly similar. I'll provide a pattern for you, that I personally consider a good practice, and may prove to be a good general starting point for further expansion.

Start with 4 roles with no properties themselves. Put 'read', 'insert', 'update', and 'node-update' in the names.

Create a fifth role with 'defaults' in the name and give it default permissions for the above four roles, where the capability matches the role name (so 'read' for the read-role, etc).

Then create higher level roles for abstract notions like reader, writer, and maintainer. Reader only inherits the read role, writer inherits reader, insert, update and defaults. Maintainer inherits writer. Deletion is a special kind of update, and not distinguishable. Node-update is a subset of update. I have not come across a use case where I wanted to allow node-update, but not a full update.

Execute permissions makes no sense here, since that only applies to modules, not to documents. Execute privileges are used to allow using particular functionality (like sem:sparql, xdmp:http-get, etc). Apply them as appropriate to reader and writer roles.

Avoid applying more dangerous execute privileges like xdmp:spawn, and xdmp:eval to any of the above roles. If you come across a need for that, then create a role that you use for Amps (you can put 'amps' in the name somewhere), and make sure you use that role only for Amps, and never assign it to roles or users.

Last but not least, you often have multiple distinct datasets in the same database, and you might want to control document access to them independently. Consider looking into Compartment Security instead of creating a distinct set of roles per dataset in such cases.

HTH!

Upvotes: 1

Related Questions