A security model for data integration

by Caio Milani

In my previous blog about Brexit, I talked about using MarkLogic server roles and document-level permissions to create an adaptable security model, ready for regulation changes that might come as the United Kingdom exits European Union (EU). But what if the piece of information that I need to assert access control is inside a document? For instance, the new regulation allows U.K. users to see some information about European citizens but not all.

With similar problems in mind, we are introducing in MarkLogic 9 a new feature called Element-Level Security that allows you to control what parts of a document are visible to users. Let's continue with the EU example and show how to create a security model to comply with current privacy export restrictions or even to accommodate any changes that may happen.

Here 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, including name, address, and phone number, and financial information such as property, premium, and currency. Here is a simple representation:

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.

As in the previous blog, we will adopt granular permissions and a hierarchical role-based access control model, but now we add elements to the mix.

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 have xdmp: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, that 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 European Union will be assigned the EU_privacy role and outsiders will be assigned EU_nonprivacy. This is core capability already available in MarkLogic 8. EU_privacy inherits all CountryName_PII and all CountryName. The function call below is summarized. (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 with be able to see the <client-information>, while others who log in with EU_nonprivacy won't. 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. For those who are participating in the Early Access program, see the EA website to learn more about Element-Level Security.