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:

<policy>
  <client-information>
    <name>John</name>
    <address>999 Broadway</address>
    <phone>444-333-1234</phone>
    <country>UK</country>
  </client-information>
  <policy-information>
    <property-type>Home</property-type>
    <premium>450</premium>
    <asset-value>800,000</asset-value>
    <currency>Euro</currency>
  </policy-information>
</policy>

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

• Blog: How to prepare your security model for Brexit
• Docs: MarkLogic Security Model chapter of the Security Guide
• Blog: Element Level Security Performance