Magnolia 5.4 reached end of life on November 15, 2018. This branch is no longer supported, see End-of-life policy.
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.
Roles are also used when configuring App permissions.
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:
website
, dam
or templates
. A single ACL can contain rules for several workspaces.For example, the following ACL gives editors a permission to edit news pages under siteA/news
.
Workspace | Permission | Scope | Path |
---|---|---|---|
website | 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 |
---|---|---|---|
website
| Deny access | Selected and sub nodes |
|
Read-only | Selected and sub nodes |
| |
Read/Write | Sub nodes |
|
Website
, click Add new to create a rule.With the Web access tab you can define URL permissions for access to every Magnolia resource. One ACL grants access to a path for Get or 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.
The Enterprise Edition allows you to manage multiple websites in a single Magnolia instance. You can control cross-site access in two ways:
<site>
parameter in the path to make an ACL site specific. See the <demo-project>
example above.CrossSiteSecurityFilter
grants 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.
When a user signs into Magnolia, the system collects all their ACLs, including:
When the user attempts to access a resource, Magnolia tests all the ACL rules the user has inherited to determine 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 is not considered. This is a critical point to note, although this criterion is only applied 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 his roles, groups' roles and nested groups' roles.
Workspace | Permission | Scope | Path | Comments |
---|---|---|---|---|
website | 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. |
Simply assigning a user to all roles and all groups may not result in the broadest possible access for the user 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 is governed by more than one rule will behave according to the "longest pattern" principle.
Magnolia stores users, groups, roles and ACLs in separate workspaces.
Workspace | What is stored |
---|---|
| Users (includes system, admin and public users) |
| Groups |
| Roles and ACLs. Since ACLs are always attached to roles, they are stored in the same workspace. |
In order 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.
/path/to/node
./path/to/node/*
. The asterisk means "everything under this"./path/to/node
and /path/to/node/*
. Together they mean "this node and everything under it".Examples:
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.
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
$
.
Example: You have a page /news/sports
and you want to grant sports editors the ability to edit that page, its properties and its subpages, but don't want them deleting the page. Create the following ACL rules in the website
-controlled workspace:
Workspace | Permission | Scope | Path |
---|---|---|---|
website | 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 but the second is longer, therefore 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.
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 a permission to access the system and launch non-restricted apps, but without access to content:
Note that in a multisite environment the ACLs are site aware and the root node is then referenced with *
(without the leading slash).