Roles and access control lists

Access to resources is controlled by roles set up in the Security app.

Roles

A role is a function a user performs in the management of a Magnolia website. It reflects the actions and activities assigned to or required or expected of a user. For example, the role Editor is responsible for day-to-day editing of content displayed on the site. Permissions granted to the editor role allow users in this role to edit content and submit it for review. The publisher role on the other hand is tasked with reviewing content and publishing it from the authoring instance to public instances. Roles have ACLs and Web access permissions.

ACL structure

Magnolia allows you to define different ACLs for each role. With this method you can assign exact access credentials.

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

An 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, for example 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 attached gives editors permission to edit news pages under siteA/news.

The power of ACLs is in the combination of 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 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. Save changes.

Web access

On the Web access tab you can set permissions for site URLs. This allows you to control what parts of the site a role can 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.
• 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 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 node 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 node 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 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 they have no access to content. Note that in a multisite environment the ACLs are site aware and the root node is then referenced with * (without leading slash).