The persistence layer of Hippo CMS is the Hippo Repository, a JCR compliant repository on top of Apache Jackrabbit. Content in a JCR repository is typically accessed through a JCR session, which has read/write (and possibly other) privileges to certain JCR nodes. The JCR specification nor Jackrabbit however cater for a possibility to combine the access and privileges of two sessions, optionally restricted with on the fly new constraints. This is one of the nice features we recently added to Hippo Repository (available from CMS 7.7.10 and 7.8.4).

General Concept of Session Security Delegation

For a complete technical understanding of Hippo CMS authorization,  you can best read Repository Authorization and Permissions and Session Security Delegation. For a general concept, the pictures below should be enough. 

Through repository security configuration, you can configure which sessions have which access to which JCR nodes. Below an example of read access for two different sessions.

 

With Hippo Repository, combining the  access / roles for the above two JCR Sessions has become trivial as explained in  Session Security Delegation

Use Case Examples

Example 1

Preview pages in the channel manager in the CMS are rendered by default with a JCR session from the previewuser session pool.  In general, the previewuser is allowed to read documents that are not very sensitive or as a minimal required to have a working preview site. But now suppose you are an editor that is allowed to work on very sensitive documents, that are not allowed to be read by any other cms user. Arranging the access rules in such a way that the previewuser and other users cannot read your documents is basic authorization and permissions configuration. But, if the previewuser is not allowed to read your highly sensitive document, then how to preview it in the preview channel? This works by default from 7.9.0 and higher (and for earlier versions you need to set a property in hst.properties as follows:

cms.preview.security.delegation.enabled = true

It works because with security delegation enabled, when you access the preview channel in the channel manager, you get the read access of the previewuser + [the read access of your logged in cms user  -/- the read access on drafts and live]. 

Example 2  

The Hippo Delivery Tier (HST) by default renders public pages with a JCR session from the liveuser session pool. When you have a site where visitors can authenticate via login, you can configure that the site needs to render pages with a JCR session belonging to this authenticated visitor. If this authenticated visitor is a cms editor, you want the authenticated visitor to have read access to 

  1. All the nodes the liveuser (for anonymous visitors)  can read 
  2. All the live nodes the cms editor can read (thus not the preview or draft documents he can read) 

Typically, the above is very useful if you have cms editors/authors that have read/write access to a very little part of the repository, but it might just be some documents that the default liveuser has no read access for.

The Embargo Forge Plugin : A real live use case

The embargo plugin allows you to put CMS documents under embargo, that is, it adds a flag that sets the documents in a confidential state. No one has access to a document under embargo unless he belongs to the group that set the embargo flag. Groups can be given the embargo privilege by adding them to the embargo security domain. Thus, new users and new groups can be added and enabled for embargo operations. These groups don't see each other's embargo. In the preview channel in the channel manager, documents under embargo can be previewed only by the cms users that have read access to the documents under embargo. See Hippo Embargo Plugin for the complete documentation.