Security Domains

A security domain defines a set of repository nodes for which you can configure specific access privileges. These privileges can be assigned to users, groups, or users with a specific user role.

Domains Configuration

Domain Folder

General security domains are stored in the repository as child nodes of the security domain folder at /hippo:configuration/hippo:domains. This node is of type hipposys:domainfolder.

Node Type Definition

[hipposys:domainfolder] > nt:base
+ * (hipposys:domain) = hipposys:domain
copy

Federated Domain Folders

You can also define security domains as children of federated security domain folder nodes, which use the node type hipposys:federateddomainfolder.

Federated domain folders restrict security domain facet rules so they only apply to nodes within the parent path of the federated domain folder. Facet rules such as jcr:path or jcr:uuid must use a path value relative to this parent path.

For example, the Poll Plugin stores poll results under /polldata. When you add the poll plugin, it creates a security domain at /polldata/poll:domains that defines access rights for /polldata and its descendants.

Node Type Definition

[hipposys:federateddomainfolder] > hipposys:domainfolder
copy

Security Domain

Security domain nodes use the node type hipposys:domain and must contain at least one domain rule child node.

Node Type Definition

[hipposys:domain] > nt:base
+ * (hipposys:domainrule) = hipposys:domainrule
+ * (hipposys:authrole) = hipposys:authrole
- hipposys:description (string)
copy

Domain Rule

Domain rule nodes are of type hipposys:domainrule and serve as containers for one or more facet rule child nodes.

Node Type Definition

[hipposys:domainrule] > nt:base
+ * (hipposys:facetrule) = hipposys:facetrule
- hipposys:description (string)
copy

Facet Rule

Facet rule nodes, of type hipposys:facetrule, are used to select a set of nodes in the repository.

A facet rule consists of a facet name and a value:

• The facet name, stored in hipposys:facet, specifies the node property to match (for example, a document property).
• The value to match is stored in hipposys:value.

Negating

Set the hipposys:equals property to false to negate a facet rule. This matches all nodes that have the facet but not the specified value.

Filtering

When you enable filtering mode by setting hipposys:filter to true, the facet rule only applies to nodes that have the specified facet. In this mode, nodes without the facet match the rule, and nodes with the facet and the specified value also match.

Rule Types

A facet rule must use one of the following types:

• String: Standard string matching
• Name: JCR Name, used for node names and mixin types
• Reference: Looks up the UUID of a node specified by a path in the value. Matching is performed as a string comparison on the node's UUID.

Special Facet Names

• jcr:primaryType: Matches the exact node type
• jcr:mixinTypes: Matches any of the mixin types
• nodetype: Matches the exact node type or any subtype
• nodename: Matches the node name

Special Facet Values

• *: Matches any value
• __user__: Matches the current user's name
• __group__: Matches any group the current user belongs to
• __role__: Matches the current user's role for the domain

Node Type Definition

[hipposys:facetrule] > nt:base
- hipposys:facet (string) mandatory
- hipposys:value (string) mandatory
- hipposys:type (string) = 'String' mandatory < 'String', 'Name', 'Reference'
- hipposys:equals (boolean) = 'true' mandatory autocreated
- hipposys:filter (boolean)
- hipposys:description (string)
copy

Name	Type	Required	Description
node name	String	yes	hipposys:facetrule
hipposys:facet	String	yes	The facet to match. Special values: 1. nodetype: matches all nodes of the type specified in hipposys:value. 2. jcr:uuid: matches the node at the absolute path specified in hipposys:value. hipposys:type must be Reference. 3. jcr:path: matches all nodes at or below the absolute path specified in hipposys:value. hipposys:type must be Reference. The hippo:paths facet is deprecated; use jcr:path instead to avoid leaving nodes unsecured.
hipposys:value	String	yes	The value to match. Special values: - *: match any value - __role__: match the current user's role for the domain - __user__: match the current username - __group__: match any of the current user's groups. For Boolean, Long, or Double properties, use their string representations (e.g., "10.1" for Double, "true" for Boolean).
hipposys:type	String	yes	The property type of the facet. Must be String, Name, or Reference.
hipposys:equals	Boolean	yes	Determines if the value must match (true) or must not match (false). If set to false, the rule only applies if the facet exists.
hipposys:filter	Boolean	no	If set to true, the rule only applies if the facet exists.

The hipposys:filter property affects matching behavior when hipposys:equals=true and the facet does not exist. In this case, setting hipposys:filter=true includes the node; otherwise, it is excluded.

	hipposys:filter=false (default)		hipposys:filter=true
facet exists	facet doesn't exist	facet exists	facet doesn't exist
hipposys:equals=true	match: include !match: exclude	exclude	match: include !match: exclude	include
hipposys:equals=false	match: exclude match: include	include	match: exclude !match: include	include

Authrole

Security domains can include one or more authrole child nodes of type hipposys:authrole. Each authrole grants a specific repository role—and its associated privileges—to users, groups, or users with a specific user role for the selected nodes in the domain.

hipposys:authrole Node Type Definition

[hipposys:authrole] > nt:base
- hipposys:users (string) multiple
- hipposys:groups (string) multiple
- hipposys:userrole (string)
- hipposys:role (string) mandatory
- hipposys:description (string)
copy

Name	Type	Required	Description
node name	String	yes	The name of the authrole
hipposys:role	String	yes	The repository role to grant to the configured users, groups, or users with the user role, for the selected nodes in the domain.
hipposys:users	String	no	The users who are granted the repository role in the domain.
hipposys:groups	String	no	The groups who are granted the repository role in the domain.
hipposys:userrole	String	no	The user role required for users to be granted the repository role in the domain.

Implicit Read Access to Ancestors

If a domain rule includes a jcr:path facet rule as a hierarchical allowlist constraint, with:

1. hipposys:facet = jcr:path
2. hipposys:equals = true
3. hipposys:value = /some/path/subpath

then all ancestor nodes of /some/path/subpath automatically receive implicit read access (jcr:read) for a user, provided that:

1. No other facet rules in the domain rule exclude /some/path/subpath from matching
2. The domain includes at least one authrole granting jcr:read privilege to the user

This implicit ancestor read access is available starting from version 14.0.0. It simplifies the configuration of privileges for users at deeper repository nodes.

Facet rules using jcr:path and jcr:uuid both use absolute path values for configuration. However, jcr:uuid facet rules do not apply to descendants of the path, and implicit read access to ancestors is only available for jcr:path facet rules—not for jcr:uuid.

Custom Security Domains

When creating custom security domains, use the Console to view a user's permissions on specific nodes. This feature is available from version 14.0.0. For details, see View Permissions of a User in the Console.

Note: Security domains are configuration (except for some system properties).

For more information about configuration categories, see Configuration vs Content (vs System).

Because security domains are configuration, ensure that changes to security domain configuration are included in local bootstrap. Otherwise, custom domains, domain rules, or authroles may be deleted during new deployments.

Users with the xm.security.application-admin user role can modify authroles within security domains at runtime, for example through the CMS UI (Setup > System > Permissions). To persist these changes, enable auto-export and ensure changes are included in the bootstrap configuration. If you make changes directly in production, reconcile them into the bootstrap configuration—using the Configuration Verifier if needed—before the next deployment to avoid losing changes.

Examples

• Deny Access to a Folder
• Grant Access to One Channel Only