Performance Considerations with Protected Paths
The fewer protected paths that you have in your documents, the better performance you will have with element level security. One way to reduce the number of protected paths is to group information. If you have the ability to control the schema of your documents, you can group information that you want to protect under one element and then protect that element.
In this example, an insurance company has a schema that groups policy information to control access to the information, making it easier to protect client information and policy information by role (US Read, ID_Read, Compliance, and Risk):
"policy": {
"access": "US Read",
"client": {
"access": "ID_Read",
"name": "Paul",
"address": "999 Broadway St",
"phone": "323-344-1555",
"country": "US",
"ssn4digits": "5664"
}
,
"clientSSN": {
"access": "Compliance",
"ssn": "999-999-5664"
}
,
"clientIncome": {
"access": "Risk",
"income": "44,4444"
}
,
"info": {
"access": "Risk",
"propertyType": "Home",
"premium": 432,
"assetValue": 750000,
"currency": "Dollar"
}
}
Different users would be able to see different parts of the data: the Call Center might have the ID_Read role, the Financial Risk Researcher might have the Risk role, and a Compliance Admin might have the ID_Read, Risk, and Compliance roles. Each of these would all need to have the US Read role as well.
If you don’t have control of the schema and your document data is in various formats, you can leverage Entity Services as a way to improve performance. You can use entity services to create an entity that groups multiple elements under a single node and then use a single protected path on that node. See Introduction to Entity Services in the Entity Services Developer’s Guide for information about creating an entity that links to the source document and protecting both.