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.
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 belong to the role either directly or through groups have the permissions granted in the ACL.
ACLs are defined in Roles in the Access control lists tab.
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.
-
Scope. Does the permission apply to the selected node only or also to its sub nodes?
-
Path pointing to the node that is controlled.
For example, the following ACL gives editors permission to edit news pages under siteA/news.
| Workspace | Permission | Scope | Path |
|---|---|---|---|
|
Read/Write |
Sub nodes |
|
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 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 | Scope | Path |
|---|---|---|---|
|
Deny access |
Selected and sub nodes |
|
Read-only |
Selected and sub nodes |
|
|
Read/Write |
Sub nodes |
|
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.
-
Go to the Access control lists tab.
-
Next to the workspace such as
Website, click Add new to create a rule. -
Select:
-
Permission: Read-only, Read/Write or Deny access.
-
Scope: Selected node, Selected and sub nodes, or Sub nodes.
-
Path: Browse to the controlled object.
-
-
Click Save changes.
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.
-
Click the Roles tab.
-
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 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 tab, click Add new.
-
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.
A sports editor attempts to edit a sports story on page /siteA/news/sports.
The user has inherited the following ACL rules through his roles, groups' roles, and nested groups' roles.
| Workspace | Permission | Scope | Path | Comments |
|---|---|---|---|---|
|
Read-only |
Selected and sub nodes |
|
|
Read-only |
Selected and sub nodes |
|
||
Read/Write |
Selected and sub nodes |
|
Longest pattern. Used to grant permission. |
|
Deny |
Selected and sub nodes |
|
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. The choices you see in the scope dropdown are translated as follows.
-
Selected translates to
/path/to/node. -
Sub nodes translates to
/path/to/node/*. The asterisk means "everything under this". -
Selected and sub nodes translates to two regular expressions
/path/to/nodeand/path/to/node/*. 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
The Selected option is a special case available only in controlled workspaces such as config.
You can use this rule in other spaces by defining it manually with the dollar sign $.
You have a page /news/sports and 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 the website-controlled workspace:
| Workspace | Permission | Scope | Path |
|---|---|---|---|
|
Read/Write |
Selected and sub pages |
|
Read-only |
Selected and sub pages |
|
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 tab.
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 preventing the Security app from obtaining the root level-provided UI artefacts that are meant to be available to the partial administrator role.