Roles and access control lists
A role is a function a user performs either in the management of Magnolia or as a visitor of a Magnolia website. It reflects the actions and activities assigned to, required, or expected of a user. Specific permissions are granted to enable the functions of a role.
For example, the editor role is responsible for editing content displayed on the site. Permissions granted to this role allow the user to edit the content and submit it for review. The publisher role, on the other hand, is tasked with reviewing the content and publishing it from the author instance to the public instance(s).
Roles have JCR Access Control Lists (ACLs) and Web access permissions. For both the JCR content and Web access, you can define multiple ACLs per role.
Access to resources is controlled by the roles set up in the Security app.
Roles are also used when configuring App permissions.
| Select any role and click Role assignments in the action bar to view the users who have that role assigned to them. |
JCR ACL structure
Magnolia allows you to define different JCR ACLs for each role. With this method, you can assign exact access credentials.
A JCR ACL consists of one or more rules where permissions are applied to the controlled resource. The ACL itself defines what permission is granted. Attaching the ACL to a role defines who has the permission. Any groups and users that the role is assigned to, either directly or through groups, have the permissions granted in the ACL.
ACLs are defined in roles.
One JCR ACL specifies:
-
Workspace. ACL rules are defined per workspace, for example
website,dam, ortemplates. A single ACL can contain rules for several workspaces. -
Permission. Type of permissions applied to the controlled resource: Deny access, Read-only, or Read/Write.
-
Path. Points to the node path that’s controlled. This can be an exact node path or include subnodes through the use of the
*wildcard.
For example, the following ACL gives editors permission to edit news pages under siteA/news.
| Workspace | Permission | Path |
|---|---|---|
|
Read/Write |
|
The power of ACLs is in the combination of the rules.
The following ACL first denies access to the complete website, then specifically allows read access to /siteA and its subpages, and write access to subpages under /siteA/news.
Users whose access is controlled with this ACL can see /siteA and all its subpages but can edit only pages under /siteA/news.
| Workspace | Permission | Path |
|---|---|---|
|
Deny access |
|
Read-only |
|
|
Read/Write |
|
Creating JCR ACLs
-
Open the Security app.
-
Select the role to which you want to attach the ACL or create a new role. ACLs are always attached to roles.
-
Click Edit role.
-
In the Workspace access section, next to a workspace such as
Website, click Add new to create a rule. -
Select:
-
Path: Browse to the controlled object.
-
Permission: Read-only, Read/Write or Deny access.
-
-
Click Save changes.
| You can duplicate existing roles to speed up creation. The duplicated role is created with all the same ACLs as the original, but without any of the groups assigned. |
Controlling write access example
A common use case is a user who is permitted to publish content but not edit content.
-
Open the Security app.
-
Create a new user.
-
In the assigning roles section, grant the user the publishers role.
-
Log into Magnolia as the new user.
-
Open the Pages app and observe the status column.
Web access
In the Web access section at the bottom of the tab, you can define URL permissions for access to every Magnolia resource.
One ACL grants access to a path for Get, Get & Post, or to Deny access.
Typically, you need to at least deny the anonymous role access to AdminCentral.
On a public instance, deny the anonymous role access to AdminCentral and any members-only sections of the site.
To configure web access for a new user with an editor or publisher role:
-
In the Web access section of the role, click Add permission.
-
Create web access with Get & Post set to
/*. -
Test the setup by logging out and logging in as the new user.
Site-aware ACLs
DX Core allows you to manage multiple websites in a single Magnolia instance. You can control cross-site access in two ways:
-
Use the
<site>parameter in the path to make an ACL site specific. See the<demo-project>example above. -
The
CrossSiteSecurityFiltergrants or denies permission to a site when the site is requested through a particular domain name, preventing sibling site access.
See Cross-site security for a detailed discussion and configuration examples.
Evaluation of permissions
When a user signs into Magnolia, the system collects all their ACLs, including:
-
ACLs attached to the user’s roles.
-
ACLs attached to the user’s groups' roles.
-
ACLs attached to any of the user’s nested groups' roles.
When the user attempts to access a resource, Magnolia tests all the ACL rules the user has inherited to decide which rule matches the requested resource.
If a user has multiple ACLs through role and group assignment that specifically list the requested resource, the ACL with the longest pattern determines the permission.
| The order of the rules isn’t considered. |
This is a critical point to note, although it only applies if the user has more than one ACL that govern the requested resource. Of equally long patterns, the one that grants the broadest permissions is applied.
- Example
-
A sports editor attempts to edit a sports story on page
/siteA/news/sports. The user has inherited the following ACL rules through their roles, groups' roles, and nested groups' roles.
| Workspace | Permission | Path | Comments |
|---|---|---|---|
|
Read-only |
|
|
Read-only |
|
||
Read/Write |
|
Longest pattern. Used to grant permission. |
|
Deny |
|
Even longer but not for the requested resource. |
Assigning a user to all roles and all groups may not result in the broadest possible access for the user. This is because ACLs are evaluated specifically in regard to the requested resources and there may be a very long rule that denies access to a particular resource.
Be sure to add users to groups and roles with the understanding that any resource that’s governed by more than one rule will behave according to the longest pattern principle.
|
ACL storage location
Magnolia stores users, groups, roles and ACLs in separate workspaces.
| Workspace | What’s stored |
|---|---|
|
Users (includes system, admin and public users) |
|
Groups |
|
Roles and ACLs. Since ACLs are always attached to roles, they’re stored in the same workspace. |
ACL rules are stored as regular expressions
To understand the pattern length criterion, it helps to look at how Magnolia stores the ACL rules internally. Each rule is translated into one or more regular expression patterns.
-
/path/to/nodetranslates to the selected path. -
/path/to/node/*translates to sub nodes. The asterisk means "everything under this". -
Two regular expressions
/path/to/nodeand/path/to/node/*translates to the selected node and its sub nodes. Together they mean "this node and everything under it".
| Scope | Path | Translated to a regular expression |
|---|---|---|
Selected |
|
|
Sub pages |
|
|
Selected and sub pages |
|
|
When Magnolia searches for the longest matching pattern, it compares the length of the regular expression patterns, not the length of the path you select.
Marking the end of a path
Use the RegEx metacharacter $ to mark the end of a path.
- Example
-
You have a page
/news/sportsand you want to grant sports editors the ability to edit that page, its properties, and its subpages. You don’t want them to be able to delete the page. Create the following ACL rules in thewebsite-controlled workspace:
| Workspace | Permission | Path |
|---|---|---|
|
Read/Write |
|
Read-only |
|
The first rule grants write permission to the page and all its children.
The second rule grants read-only permission to the page itself, not affecting permissions to the page properties.
When the system evaluates permissions for /news/sports, both rules are valid.
However, the second rule is longer, therefore it’s evaluated as more appropriate and applied.
When the system evaluates permissions for subpages like /news/sports/NBA, only the first rule matches.
The second doesn’t because the $ sign marks the end, so the editor has complete control of all the subpages.
App launcher access
In order for users to access Magnolia via the app launcher, they need at least the Get & Post permissions to the root node (/) in the *Web access section.
This gives the user permission to access the system and launch non-restricted apps, but without access to content.
In a multisite environment, the ACLs are site aware and the root node is then referenced with * (without the leading slash).
|
Partial administrator roles
If you want to create a partial administrator role whose management permissions are limited to specific user, role, or group subfolders, you need to add read dialog permissions explicitly to such a partial role.
This is because, when restricting root access to permit modification of subfolders only, you are at the same time you preventing the Security app from obtaining the root level-provided UI artefacts that are meant to be available to the partial administrator role.