We’ve joined forces with Smartlogic to reveal smarter decisions—together.

Element Level Security: A security model for data integration

In my previous blog about preparing your security model for Brexit, I talked about using MarkLogic server roles and document-level permissions to create an adaptable security model, prepared for regulation changes in anticipation of the United Kingdom (UK) leaving the European Union (EU). But what if the piece of information that I need to assert access control lives inside a document? For example, what if the new regulation allows UK users to see some information about European citizens but not all?

In anticipation of such events, MarkLogic 9 introduced a feature called Element Level Security, which allows you to control what parts of a document are visible to users. Continuing with the EU example, we can show how to create a security model with this new feature that complies with current privacy export restrictions and accommodates any potential changes.

Below is a sample representation of element level security based on the policy records of an insurance provider that operates in the EU but is headquartered in the United States. The policy records contain information about the policy holder (e.g. name, address, and phone number) and financial information (e.g. property, premium, and currency). Here is a simple example:

    <address>999 Broadway</address>

What we want to do is to ensure that the personally identifiable information (such as name and address) represented in the <client-information> element is only available to the EU users, while the <policy-information> is shared globally inside the insurance provider.

To do this, we will adopt granular permissions and a hierarchical role-based access control model, but now we add elements to the mix (also done in my previous blog).

Once a document is created, its permission to read is set according to a role that defines the policy-holder location using the convention country_locale.

For example, a policy for a French resident would have xdmp:permission("france_locale", "read"), a policy in London would have xdmp:permission("england_locale", "read"), and a policy holder in Edinburgh would havexdmp:permission("scotland_locale", "read").

In order to protect the <client-information>, we will leverage element level security. Element level security uses XPath to find the information inside the document, known as the protected path, which needs to have additional access control. Each protected path is associated with a role and a capability. The simplified function signature is sec:protect-path(xpath, permissions).

In our scenario, the path in the document that needs to be protected is the client information, and the role is based on the country.

For example, the expression /root/client-information[country="UK"] will match the <client-information> node if <country> is UK. Each protected path will be associated with a privacy role for which I am using the convention CoutryName_PII, such as Italy_PII, and so on. Therefore, we will have one protected path per country.

Here are two examples:

  • xdmp:protect-path(/root/client-information[country="UK"], xdmp:permission("UK_PII", "read"))
  • xdmp:protect-path(/root/client-information[country="France"], xdmp:permission("France_PII", "read"))

Now, let’s work on the hierarchical model. Users will have a role that defines their overarching legal permission. For instance, users in the EU will be assigned the EU_privacy role and outsiders will be assigned EU_nonprivacy. This is core capability has been available since MarkLogic 8. EU_privacy inherits all CountryName_PII and all CountryName. The function call below is summarized. (i.e. you have to add all countries.)

  • sec:role-set-roles("EU_nonprivacy", ("UK_locale", "france_locale")
  • sec:role-set-roles("EU_privacy", ("EU_nonprivacy", "UK_PII", "France_PII")

Now, a user who logs in with the EU_privacy role will be able to see the <client-information>, while others who log in with EU_nonprivacy will not. If you ever need to remove one country from the privacy role, such as UK, just change the role inheritance.

As you can see, MarkLogic 9 brings even more granular access control, now at the element level, that is comprehensive and flexible. Security at the document level plus the path level with XPath allows you to find the information that you need to control no matter the document structure, while the hierarchical role model allows you to quickly adapt to change.

Further Reading

Caio Milani - Director of Product Management | MarkLogic

Caio Milani is Director of Product Management at MarkLogic responsible for various aspects of the product including infrastructure, operations, security, cloud and performance. Prior to joining MarkLogic, he held product management roles at EMC and Symantec where he was responsible for storage, high availability and management products.
Caio holds a BSEE from the University of Sao Paulo and a full-time MBA Degree from the University of California, Berkeley.

Start a discussion

Connect with the community




Most Recent

View All

Unifying Data, Metadata, and Meaning

We're all drowning in data. Keeping up with our data - and our understanding of it - requires using tools in new ways to unify data, metadata, and meaning.
Read Article

How to Achieve Data Agility

Successfully responding to changes in the business landscape requires data agility. Learn what visionary organizations have done, and how you can start your journey.
Read Article

Scaling Memory in MarkLogic Server

This not-too-technical article covers a number of questions about MarkLogic Server and its use of memory. Learn more about how MarkLogic uses memory, why you might need more memory, when you need more memory, and how you can add more memory.
Read Article
This website uses cookies.

By continuing to use this website you are giving consent to cookies being used in accordance with the MarkLogic Privacy Statement.