Default Repository Authorization Setup

Default Repository Authorization Setup

In Authorization Model Concepts and descendant pages, the theory / model behind the authorization is described. It describes the 

1. Who
2. What
3. Where

With these concepts, Bloomreach Experience Manager bootstraps a default authorization setup. Below documentation assumes a plain vanilla project created with thearchetype and describes the default authorization setup. At Authentication and Authorisation Walkthroughs there are examples how to enhance the bootstrapped setup.

This page describes the default Repository authorization setup, it does not cover the feature userroles (xm.<feature>.user) described atUserroles since those userroles do not grant any Repository privileges. The default setup is described by explaining per default bootstrappedSecurity Domainwho is allowedwhat. A Security Domain covers thewhere. Also note that the default setup for Security Domains almost only uses userroles to configure the who and hardly everyhipposys:groups and/orhipposys:users. The latter are typically used for custom security domains. 

CMS/Repository Default Security domains

The described domains in this chapter are all located below /hippo:configuration/hippo:domains.

Domain: content

By default, the content domain matches every node on and below/content because it hasjcr:path = /content as constraint. It uses the following roles:

Domain: everywhere

By default matches any node througout the entire repository

Domain: frontend-config

This is the domain giving readonly priviliges to every user having userrole xm.frontend-config.reader on and below the nodes:

1. /hippo:configuration/hippo:frontend
2. /hippo:namespaces
3. /hippo:configuration/hippo:queries
4. /hippo:configuration/hippo:workflows

Read privilege to these nodes and descendants typically is needed only by CMS and Console users, hencexm.cms.user andxm.console.user inherit the userrole xm.frontend-config.reader, also seeUserroles. 

Domain: draft-document-holder-readwrite and non-publishable-readwrite

The domainsdraft-document-holder-readwrite andnon-publishable-readwrite are covered together even though they might seem very different. However, the reason for their existence is very much related, hence covered here together. With version 14.0.0, editors and authors have almost nojcr:write privilege at all any more! Almost all their actions are delegated to theworkflow session which has elevated privileges. For example publishing a document or creating a new document in a folder is done so by invoking workflow which is executed via the workflow session, not by the, say, editor session. The editor session only indicates whether the editor is allowed to invoke certain workflow actions but doesn't do the actual invocation. An exception for this is when an editor / author is editing and his/her changes get persisted into the 

1. draft document variant they are holder of or into
2. an image or asset document

Since editors/authors thus need to be able to directly write to draft documents they are holder of or to image / asset documents, we have two security domains taking care of this: 

Domaindraft-document-holder-readwrite givesjcr:write (and implicit read) to (group)everybody who is holder of a draft. So regardless which user you are, if you are the holder of the document draft, you can write to it. This makes perfectly sense since in the first place, you can only become holder of a document draft if a workflow action enabled you to become the holder in the first place.

Domain non-publishable-readwrite is there to make sure that CMS users can update an existing imageset or asset. Since imagesets and assets are not publishable documents but documents without workflow, we cannot use the fact that a user must be the holder of the variant since there never is a holder for non-publishable documents. Therefore, the domain has the what akward matching strategy to match all JCR nodes that comply to

1. Being stored below/content
2. Being documents
3. Are not publishable

Number (2) constraint looks a bit weird if you look at the actual facetrule:

/documents-only:  jcr:primaryType: hipposys:facetrule  hipposys:equals: true  hipposys:facet: hippo:availability  hipposys:type: String  hipposys:value: live

We cannot just use a nodetype constraint onhippo:document because unfortunately for legacy reasons,hippostd:folder andhippostd:directory do extend fromhippo:document nodetype. For domain non-publishable-readwrite  we have:

Domain: security-user-management

By default, the security-user-management domain matches every node on and below/hippo:configuration/hippo:groups and/hippo:configuration/hippo:users. It uses the following roles

As a result, by default users having userrole xm.default-user.cms-admin or xm.default-user.system-admin will havereadwrite access to all hipposys:groups and hipposys:users.

Domain: defaultread / versioning

These domains gives access to some JCR nodes which require read access for (group)everybody and should never have to be modified by end projects

Domain: autoexport-config

Minor domain just for the Console user being allowed tomodify the auto-export configuration to disable/enable it

Webfiles Domain

Webfiles are stored below /webfiles in the repository. The webfiles Security Domain is configured as aFederated Security Domain. Thewebfiles domain is configured at /webfiles/webfiles:domains/webfiles and givesjcr:read privilege to all JCR Nodes below/webfiles except the security domain /webfiles/webfiles:domains for users that have userrole xm.webfiles.reader. As a result, the HSTliveuser/previewuser and users having userrolexm.channel.viewer (editor/author) can read webfiles.

HST Default Security Domains

The delivery tier, aka HST, also bootstraps a set of security domains which are needed by the internal HST users for rendering requests. There are two domains (live-documents andpreview-documents) located below the default security domains location /hippo:configuration/hippo:domains and some Federated Domains which are project specific with respect to the exact location. 

Domain: live-documents

Thelive-documents domain configured below /hippo:configuration/hippo:domains givesjcr:read privilege for the HSTliveuser to all nodes below/content excluding the attic/content/attic and excluding JCR nodes that have the propertyhippo:availability not equal tolive. This domain results in that theliveuser can read all folders and the live documents.

Domain: preview-documents

The same aslive-documents, only now for thepreviewuser and excluding documents that  have the propertyhippo:availability not equal topreview.

Domain: formdata

Theformdata domain is configured at /formdata/hst:domains/formdata matches all nodes below/formdata except /formdata/hst:domains. It provides the rolereadwrite to every user having userrole xm.form.writer, which by default theHST sitewriter has. 

Domain: hstconfig

Thehstconfig domain is configured at 

/hst:myproject/hst:domains/hstconfig

where the part myproject is domain specific and different depending on your project name. Thehstconfig domain stipulates who has which role for a specific Channel. Thehstconfig domain matches all the nodes below /hst:myproject except /hst:myproject/hst:domains. 

It uses the following roles

The rolechannel-viewer enables a CMS user to view a channel, rolechannel-webmaster to modify a channel and publish their own changes, and rolechannel-admin allows a user to modify and publish their own and others' changes. 

By default, the admin user, and theadmin andcms-admin groups, have userrolexm.channel.admin, the groupwebmaster (/hippo:configuration/hippo:groups/webmaster) has userrolexm.content.webmaster, and groupseditor andauthor have userrolexm.channel.viewer.

Relevance Default Security Domain

TheRelevance Module (formerly calledTargeting) bootstraps its security as a Federated Domain Security at /targeting:targeting/targeting:domains/targeting. It matches all nodes below/targeting:targeting except the domain itself  (/targeting:targeting/targeting:domains and descendants).  

It uses the following roles

The roletargeting-viewer is for now not yet implemented but will in the future support users who have only read access to the Relevance dashboard. The roletargeting-editor gives next to the Relevance dashboard read access alsojcr:write to/targeting:targeting and descendants giving users having that privilege the ability to edit different Relevance parts. AtUserroles you can see which userroles inherit thexm.targeting.editor userrole.

Projects Default Security Domain

TheProjects Module bootstraps its security as a Federated Domain Security at /hippowpm:hippowpm/hippowpm:domains. It matches all nodes below/hippowpm:hippowpm/hippowpm:projects.

It uses the following roles

See Userroles for the descriptions what the userroles above imply and which userroles inherit which project related userrole.

Plugins Default Security Domains

Polldata is stored below /polldata in the repository and used as storage location for thePoll Plugin. The polldata Security Domain is configured as aFederated Security Domain and gets bootstrapped when using the Poll Plugin. It is stored at /polldata/poll:domains/polldata and matches all JCR Nodes below/polldata except the security domain /polldata/poll:domains. 

It uses the following roles