How to prepare your security model for Brexit

In Kasey’s post about security in Samplestack, we learned some tips and recommendations about using roles. How can we use them to prepare for the consequences of the Brexit or any other exits? This unprecedented decision of a country to leave the European Union will certainly cause severe uncertainty and very likely changes to financial regulation for banks. British branches that were subject to European directives may have to adapt to new British regulation while still complying to some European regulation. Let’s take the case of a global bank that will have to operate on both sides of the channel.

Current European regulation hints that in the future, information about European citizens and businesses may not be allowed to leave European borders. For instance, employees working on the London branch would not be able to access some documents created in the French branch of the bank. To prepare for this possible outcome, MarkLogic administrators should start adopting granular permissions and a hierarchical role-based access control model.

Let me demonstrate this with a simple use case based on document creation location. Once a document is created, its permission to read is set according to a role that defines the location; for instance, a document created in France would have xdmp:permission("france_locale", "read"), one in London xdmp:permission("england_locale", "read"), one in Edinburgh xdmp:permission("scotland_locale", "read").

In order to create an abstraction that would allow MarkLogic administrators to quickly adapt to the new regulation, we will use an indirect role model. Users will have a role that defines their overarching legal permission. For instance, users in the European Union will be assigned the EU_law role and outsiders the NON-EU_law. EU_law inherits france_locale and every other country in the E.U., which as of today still includes england_locale, scotland_locale, etc.

When the United Kingdom finally exits the European Union, rather than updating all documents to change permissions, the administrator will just create a new overarching role called UK_law that inherits UK members, e.g., england_locale, scotland_locale, add these locales to NON-EU_law as well and, finally, remove england_locale, scotland_locale from the EU_law role. This will trigger an update to the security database but not an update to all documents, which could lead to a very large amount of merging. After this update, employees of the London branch who should be part of the UK_law role will not be able to access documents created inside the European Union, but will still be able to see documents created in London or Edinburgh.

This model also prepares for later changes. If Scotland later leaves the United Kingdom, in a similar manner, the administrator would create a Scotland_law role that inherits scotland_locale and remove scotland_locale from UK_law.

In sum, we learned that it’s best practice to use granular roles (e.g. country in this example) for document permissions, and to use business-level roles (government/law unit), which are assigned to users. This model allows quick changes to access control that do not trigger document updates and reindexing, which means that you can perform security changes anytime and not be concerned about massive I/O in your database.