MarkLogic has a role-based security model, which makes roles very powerful. Application developers must keep that power in check when designing security. Assigning a role to your custom application role means it inherits not only access privileges, but also document permissions.
Using MarkLogic's Role-Based Security Model as a starting point – where roles are central:
Privileges control what actions a role can perform. Document permissions restrict what content a role can view. MarkLogic provides fine-grained control for custom role definitions so that the right combination of privileges and permissions can be used. Developers should consider using privileges to provide access instead of MarkLogic's out-of-the-box roles, which may unwittingly expose restricted content to end-users. Samplestack encountered this scenario and illustrates the design pattern to use the
rest-reader privilege instead of the
rest-reader role for its application-specific security model.
Samplestack requires two types of app-level users - anonymous Guests and logged-in Contributors. Guests are restricted to seeing only those 'Question and Answer' (QnA) threads with an 'accepted answer', whereas Contributors can see all content. The real-world corollary is a scenario where outsiders can only see finished or published content whereas content owners/editors can see the private work in progress.
Requirement to restrict visibility of Question & Answer documents for Samplestack roles
Two components of the role-based security model that can be applied here are permissions on the documents and application role definitions (privileges and assigned roles).
Here is the relevant portion of the security model Samplestack implemented to enforce the restricted content requirement:
|Database User is:||samplestack-guest||samplestack-contributor|
|has Database Role:||samplestack-guest||samplestack-writer|
|is assigned (& inherits) roles:||rest-extension-user||samplestack-guest (rest-extension-user), rest-reader, rest-writer|
|is assigned (& inherits) privileges:||rest-reader||(rest-reader, rest-writer)|
A natural inclination might be to give the Guest the
rest-reader role since Guests can view (some) content and do so via the Client API. However, it provides a possible loophole where the Guest could view more content than allowed.
From the REST Application Developer's Guide:
By default, documents you create with the MarkLogic REST API have a read permission for the
rest-readerrole... a user with the
rest-readerrole can read all documents created with the REST API.
To enable users to [read] documents using the REST API yet restrict access, use custom roles with the
rest-readerprivileges and suitable default permissions, rather than relying on the pre-defined
As you can see, the
rest-reader role has special access, so you may want to avoid using it for the basis of your own application role hierarchy.
Samplestack took these guidelines as inputs to making the following decisions:
- Created custom application-specific roles
- Used privileges rather than assigning out of the box roles
- Applied document permissions for custom roles, rather than relying on pre-defined, MarkLogic-supplied roles
Limiting Guests to viewing documents using the explicit, application-specific
samplestack-guest permission also gives application developers more fine-grained control over document visibility for their users in a scenario where other applications share the same database and could insert unknown content.
Check out the configuration yourself in the Samplestack GitHub repository.
- Configuration file defining the
samplestack-guestrole with the
- Ingestion process to add
samplestack-guestpermission to questions with accepted answers
- Updating document permissions to include
samplestack-guestrole on accepted answer
Another approach would have been to create a layer of abstraction between the document state/permission and the user role. For example, a permission called
accepted-answer could be applied to documents with accepted answers. The
samplestack-guest role would be assigned the
accepted-answer role. Abstracting the document permission away from the specific application role means some changes in access for guests would not require updating and re-indexing every document.
Thank you to the Samplestack engineers, Charles Greer and Daphne Maddox for review, to Caio Milani for security input, and to Mitch Yawitz for design assistance.