Exercising Privilege to Restrict Content

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.

Application Requirement

Requirement to restrict visibility of Question & Answer documents for Samplestack roles

Implementation

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:

Design Considerations

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-reader role… a user with the rest-reader role 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-reader privileges and suitable default permissions, rather than relying on the pre-defined rest-reader.

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-guest role with the rest-reader privilege
• Ingestion process to add samplestack-guest permission to questions with accepted answers
• Updating document permissions to include samplestack-guest role 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.