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 the archetype 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 at Userroles since those userroles do not grant any Repository privileges. The default setup is described by explaining per default bootstrapped Security Domain who is allowed what. A Security Domain covers the where. Also note that the default setup for Security Domains almost only uses userroles to configure the who and hardly every hipposys:groups and/or hipposys: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 has jcr:path = /content as constraint. It uses the following roles:

who (userrole)	role
xm.content.admin	admin
xm.content.author	author
xm.content.editor	editor
xm.content.viewer	readonly

Domain: everywhere

By default matches any node througout the entire repository

who (userrole)	role
xm.repository.admin	admin
xm.repository.reader	readonly

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, hence xm.cms.user and xm.console.user inherit the userrole xm.frontend-config.reader, also see Userroles. 

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

The domains draft-document-holder-readwrite and non-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 no jcr:write privilege at all any more! Almost all their actions are delegated to the workflow 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: 

Domain draft-document-holder-readwrite gives jcr: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 on hippo:document because unfortunately for legacy reasons, hippostd:folder and hippostd:directory do extend from hippo:document nodetype. For domain non-publishable-readwrite  we have:

who (userrole)	role
xm.content.author	readwrite

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

who (userrole)	role
xm.security.viewer	readonly
xm.security.user-admin	readwrite

As a result, by default users having userrole xm.default-user.cms-admin or xm.default-user.system-admin will have readwrite 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 to modify 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 a Federated Security Domain. The webfiles domain is configured at /webfiles/webfiles:domains/webfiles and gives jcr: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 HST liveuser/previewuser and users having userrole xm.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 and preview-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

The live-documents domain configured below /hippo:configuration/hippo:domains gives jcr:read privilege for the HST liveuser to all nodes below /content excluding the attic /content/attic and excluding JCR nodes that have the property hippo:availability not equal to live. This domain results in that the liveuser can read all folders and the live documents.

Domain: preview-documents

The same as live-documents, only now for the previewuser and excluding documents that  have the property hippo:availability not equal to preview.

Domain: formdata

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

Domain: hstconfig

The hstconfig domain is configured at 

/hst:myproject/hst:domains/hstconfig

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

It uses the following roles

who (userrole)	role
xm.channel.admin	channel-admin
xm.content.webmaster	channel-webmaster
xm.content.viewer	channel-viewer

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

By default, the admin user, and the admin and cms-admin groups, have userrole xm.channel.admin, the group webmaster (/hippo:configuration/hippo:groups/webmaster) has userrole xm.content.webmaster, and groups editor and author have userrole xm.channel.viewer.

Relevance Default Security Domain

The Relevance Module (formerly called Targeting) 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

who (userrole)	role
xm.targeting.editor	targeting-editor
xm.targeting.viewer	targeting-viewer

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

Projects Default Security Domain

The Projects 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

who (userrole)	role
xm.project.admin	project-admin
xm.project.editor	project-editor
xm.project.viewer	project-viewer

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 the Poll Plugin. The polldata Security Domain is configured as a Federated 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

who (users)	role
sitewriter	readwrite
liveuser, previewuser	readonly