Securing MarkLogic Server

A protected path set is a way to allow multiple protected paths covering the same element, with both AND and OR relationships between the permissions. This enables multiple arbitrary security marking for an element.

A protected path set is an optional string that represents the name of a set is associated with a protected path. A path that has no “set name” can be seen as a “degenerated form” of a set. The diagram below shows how permissions from paths in the same set are ORed, while permissions between sets are ANDed.

The set information (the name) is simply a “tag” on the protected path definition, not a separate document in the Security database.

Consider the following element:

<foo classification="TS" releasableTo="USA GBR AUS">

Using protected paths, MarkLogic Server element level security allows multiple protected paths covering the same element with an AND relationship among their permissions. This models a multiple security markings (for example @classification and @releasableTo) situation well. For the element above, two protected paths may be defined:

//foo[@classification="TS"] ("Role_TS", "read")

//foo[@releasableTo="USA GBR AUS"] (("Role_USA", "read"), ("Role_GBR","read"), ("Role_AUS","read"))

Note that the value of @releasableTo is a list of country codes, with each mapping to a role. A user with any of the “country roles” is allowed to read the element. The challenge is that a list can contain an arbitrary combination of country codes (total 200+). The above approach would require a user to define one protected path for each of the possible combinations, which may lead to a very large number of protected paths:

//foo[fn:contains(@releasableTo, "USA")] ("Role_USA", "read")

//foo[fn:contains(@releasableTo, "GBR")] ("Role_GBR", "read")

//foo[fn:contains(@releasableTo, "AUS")] ("Role_AUS", "read")

The following example shows the benefit of the path set concept more clearly. Consider the following elements to be protected:

<foo classification="TS" releasableTo="USA">

<foo classification="TS" releasableTo="GBR">

<foo classification="TS" releasableTo="AUS">

<foo classification="TS" releasableTo="USA GBR">

<foo classification="TS" releasableTo="GBR AUS">

<foo classification="TS" releasableTo="USA AUS">

<foo classification="TS" releasableTo="USA GBR AUS">

Without using protected path sets, the following protected paths would need to be defined to protect the elements above:

//foo[@classification="TS"] ("Role_TS", "read")

//foo[@releasableTo="USA"] ("Role_USA", "read")

//foo[@releasableTo="GBR"] ("Role_GBR","read")

//foo[@releasableTo="AUS"] ("Role_AUS","read")

//foo[@releasableTo="USA GBR"] (("Role_USA", "read"), ("Role_GBR","read"))

//foo[@releasableTo="GBR AUS"] (("Role_GBR","read"), ("Role_AUS","read"))

//foo[@releasableTo="USA AUS"] (("Role_USA", "read"), ("Role_AUS","read"))

//foo[@releasableTo="USA GBR AUS"] (("Role_USA", "read"), ("Role_GBR","read"), ("Role_AUS","read"))

With protected path sets, only these protected paths are needed:

//foo[@classification="TS"] ("Role_TS", "read")

//foo[fn:contains(@releasableTo, "USA")] ("Role_USA", "read") "SetReleasableTo"

//foo[fn:contains(@releasableTo, "GBR")] ("Role_GBR", "read") "SetReleasableTo"

//foo[fn:contains(@releasableTo, "AUS")] ("Role_AUS", "read") "SetReleasableTo"

The total number of protected paths required for the @releasableTo attribute is reduced from 7 to 3 using the SetReleasableTo protected path set.

In real world systems, the total number of possible country codes for these examples are more than 200, which leads to millions of possible combinations. So, with protected path sets, the number of required protected paths can be reduced from millions to just a couple of hundred for the @releasableTo use case.