Bloomreach Experience Manager Roles & Permissions | OpsBlu Docs

Bloomreach Experience Manager Roles & Permissions

Bloomreach Experience Manager (brXM) role and permission architecture -- CMS security domains, repository roles, and analytics access control.

Bloomreach Experience Manager (brXM, formerly Hippo CMS) uses a JCR repository-based permission model with security domains, roles, and groups for fine-grained content and configuration access.

Role Architecture

brXM separates roles into two layers: CMS roles (authoring interface access) and repository roles (JCR node-level permissions).

Built-in CMS Roles

Role Content Authoring Channel Manager Publish Admin Console Configure Channels
admin Yes Yes Yes Yes Yes
editor Yes Yes Yes No No
author Yes No No No No
webmaster No Yes No No Yes

Security Domains

Permissions are organized into security domains that map repository paths to roles:

# Security domain structure in /hippo:configuration/hippo:security/hippo:domains/
content-domain:
  folder-read:
    match: /content/documents/**
    role: readonly
  folder-write:
    match: /content/documents/myproject/**
    role: readwrite
admin-domain:
  config-access:
    match: /hippo:configuration/**
    role: admin

Permission Matrix

Permission admin editor author webmaster
Read content Yes Yes Yes No
Create documents Yes Yes Yes No
Edit documents Yes Yes Yes No
Publish/unpublish Yes Yes No No
Delete documents Yes Yes No No
Manage channels Yes Yes No Yes
Admin console access Yes No No No
Manage users/groups Yes No No No
Repository configuration Yes No No No

Creating Custom Roles

Define custom roles in the repository configuration or via the Admin Console at Admin > Security > Roles:

# Custom analytics-manager role definition
definitions:
  config:
    /hippo:configuration/hippo:security/hippo:roles/analytics-manager:
      jcr:primaryType: hipposys:role

Analytics-Relevant Permissions

Analytics scripts in brXM are managed through HST page components (requires webmaster/admin), Freemarker templates (requires repository access), or Channel Manager head contributions:

<#-- base-layout.ftl: Add analytics before </head> -->
<head>
  <@hst.headContributions categoryExcludes="htmlBodyEnd" xhtml=true/>
  <script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
  <script>
    window.dataLayer = window.dataLayer || [];
    function gtag(){dataLayer.push(arguments);}
    gtag('js', new Date());
    gtag('config', 'G-XXXXXXXXXX');
  </script>
</head>

REST API Access

# List users via the REST API
curl -u admin:admin "http://localhost:8080/cms/ws/users/" -H "Accept: application/json"

API tokens inherit the permissions of the authenticated user.

Best Practices

  1. Use security domains to limit content access per project or department
  2. Never grant admin role for analytics-only tasks -- use webmaster for template access
  3. Create a dedicated analytics-manager security domain for tracking configuration
  4. Use groups rather than assigning roles directly to individual users
  5. Audit the security configuration node periodically for stale role assignments
Back to top