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.

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 or templates. 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 a permission to edit news pages under siteA/news.

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.

Creating JCR ACLs

1. Open the Security app.
2. Select a role to which you want to attach the ACL or create a new role. ACLs are always attached to roles.
3. Click Edit role.
4. Go to the Access control lists tab.
5. Next to the workspace such as Website, click Add new to create a rule.
6. 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.
7. Click Save changes.

Web access

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.

Site-aware ACLs

The Enterprise Edition 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 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.

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 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.

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.

ACL storage location

Magnolia stores users, groups, roles and ACLs in separate workspaces.

ACL rules are stored as regular expressions

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.

• 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/node and /path/to/node/*. Together they mean "this node and everything under it".

Examples:

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 $ .

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:

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.

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 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).