In this short piece I will discuss how, in BrXM (Hippo) 12 and 13, the question “Is user X allowed to perform action Y on document Z?” is answered. The Bloomreach documentation for version 12 and 13 on this subject is rich in detail but it did not help me very much to understand the big picture.

Let’s start with a diagram. Having worked exclusively with relational databases for most of my career, I instinctively tried to capture the authorization and privilege model in an Entity Relationship Diagram. Of course, the actual data model is not exactly a Third Normal Form but I found that looking at things as if it were made it clearer for me to understand.

Central in the scheme is an entity which Bloomreach calls the Security Domain. It is a conceptual construct that serves to link together the three real world elements that together make up the security model: user,  privilege and document.

A domain has a relationship to documents. This relationship is defined by looking at the Domain Rules for the domain as applied to all documents. When a document satisfies at least one domain rule of a domain, then that document is part of that domain. For a document to satisfy a domain rule the document must in turn pass all of the tests that are defined by the Facet Rules of the domain rule. One facet rule defines one such test.

By applying these requirements in practice, you will find that multiple documents can belong to the same domain, while a single document can satisfy the requirements of more than one domain and thus belong to multiple domains. So there is a many-to-many relationship between documents and domains.

The details pertaining to how the test defined by a facet rule is applied to a document is well documented by Bloomreach so I’ll refer you to them for this particular aspect.

The link between users and domains, and between privileges and domains, are both made with the aid of an entity called the Authrole. This is a purely technical construct that serves as a link between users and groups on the one hand, and privileges on the other. Users and groups are seen as a single entity in my diagram, because they are interchangeable for the purpose of being linked to privileges.

So at one end an authrole points to one or more users and groups, and at the other end it points to exactly one Role, which is nothing more than a bunch of privileges wrapped up in a named set.

I have not been able to find best practices for implementing authorization and permissions in the CMS. The Bloomreach documentation has some tips and examples but these do not delve into the do’s and don’ts for configuring domains, authroles and priviliges. Here are my two cents worth:

• Because you create relationships by adding names to list properties, typos will not be flagged. Instead, you will find that things do not work as expected, but you see no error messages. So you must apply liberal amounts of attention to detail when implementing your model.

• Although you can add individual users to the authroles, it is better to only use groups for this purpose and manage the privileges for individual users by making them members of the relevant group. This practice keeps the doling out of privileges to users localized to a single point of attack.

• The best way to view authrole is as a proxy for roles. Keep the name of your authrole node the same as the role that it points to. Reuse the same authrole names across all your domain nodes and vary the list of groups attached to the authrole, each domain having its own list tailored to the particulars of that domain. If a domain needs more than one role, add more authrole nodes to the domain.

All in all, it turns out that what at first seems a complex and unintuitive design does in fact make sense once you understand how the entities that have real world counterparts (documents, users, privileges) are connected by the more artificial constructions such as the domain, the authrole and the rules.

In version 14, an additional entity is added, the Userrole. A userrole defines functional privileges, which are global privileges (so not tied to any specific security domain). As Bloomreach explains it, “The usage and purpose of Userroles lies somewhat between Who and What”.