Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.

Page tree
Skip to end of metadata
Go to start of metadata

Access to resources is controlled with an access control list (ACL). 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.

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

ACL structure

ACLs are defined in the Edit Role dialog, on the Access Control List tab.

An ACL specifies:

  • Controlled space. ACL rules are defined per controlled space, for example Website, Data or URL. A single ACL can contain rules for several spaces. What you select in the dropdown limits the types of permissions and scopes available. For example, the "Selected node" permission is only available in Config, Store and Expressions spaces, not in the Website space.
  • Permission. Type of permissions applied to the controlled resource, for example Deny access, Read only or Read/Write. Other options are possible depending on the controlled space.
  • Scope. Does the permission apply to the selected node only or also to its sub nodes?
  • Path pointing to the object being controlled

For example, the following ACL attached to the Editor role gives editors permission to edit news pages under siteA/news.

Permission

Scope

Path

Read/Write

Sub pages

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

Permission

Scope

Path

Deny access

Selected and sub pages

/

Read only

Selected and sub pages

/siteA

Read/Write

Sub pages

/siteA/news

Creating ACLs

  1. Click Security > Roles.
  2. Select a role to which you want to attach an ACL or create a new role first. ACLs are always attached to roles.
  3. Click Edit Role.
  4. Go to the Access control list tab.
  5. Select a controlled space such as Website or Data. This selection limits the types of permissions you can assign and their scope.
  6. Create an ACL rule by selecting:
    • 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. Optional: To define more rules, click Add.
  8. Click Save.

Editing ACLs

  1. Click Security.
  2. Double-click the icon of the role the ACL is attached to.
  3. Go to the Access control list tab.
  4. Edit the ACL rules.
  5. Click Save.

Deleting ACLs

  1. Click Security.
  2. Right-click the icon of the role the ACL is attached to.
  3. Go to the Access control list tab.
  4. Click Remove on the ACL rules you want to delete.
  5. Click Save.

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.

Permission

Scope

Path

Comments

Read only

Selected and sub pages

/siteA

 

Read only

Selected and sub pages

/siteA/news

 

Read/Write

Selected and sub pages

/siteA/news/sports

Longest pattern. Used to grant permission.

Deny

Selected and sub pages

/siteA/news/sports/NHL

Even longer pattern 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.

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 in AdminCentral 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:

Scope

Path

Translated to regular expression

Selected node

/server/admin

/server/admin

Sub pages

/siteA

/siteA/*

Selected and sub pages

/siteA

/siteA
/siteA/*

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 in the AdminCentral user interface.

Marking the end of a path

The Selected node option is a special case available only in controlled spaces 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 space:

Permission

Scope

Path

Read/Write

Selected and sub pages

/news/sports

Read only

Selected and sub pages

/news/sports$

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.

URI security

A uniform resource indicator (URI) designates a method to access a resource, for example http://, and the specific resource to be accessed, for example /siteA/news. Magnolia allows you to set permissions on URIs through ACLs. URI ACL is typically used to deny "anonymous" and non-authenticated users access to the author instance.

For a public site, at minimum access to AdminCentral should be restricted by denying access to "/.magnolia*"

Site-aware ACLs

The Enterprise Edition supports multiple sites in a single Magnolia instance. You can control cross-site access through either or a combination of:

  • ACLs: The <site> parameter makes an ACL site specific.
  • Configuration: CrossSiteSecurityFilter registered in the filter chain supports parameters to prevent sibling site access.

Storage location

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

Workspace

What is stored

users

Users

usergroups

Groups

userroles

Roles and ACLs. Since ACLs are always attached to roles, they are stored in the same workspace.

Permissions for AdminCentral access

In order for users to access AdminCentral they need at least read-only access to the website root node /. In the tree views (not only in the website tree) users will only see the hierarchy and nodes according to their own permissions.

Menu

The AdminCentral menu is defined in the configuration of the adminInterface module at /modules/adminInterface/config/menu. The user will only see the menu entries to which he has at least readonly access.

Templates

In the website view the user can select the appropriate template for each page from a dropdown.

The options available in this dropdown are filtered according to the user's permissions. A template assigned to a page is visible to all users but only authorized users can assign it.

In the Standard Templating Kit (STK), the roles that can assign a particular template are defined in Templating Kit > Site Configuration > templates/availability/templates/<template name>/roles.

Note that templates can be defined in all modules. Module specific template permissions can be set by defining an ACL rule that grants access to the Config repository at /modules/<module name>/templates.

  • No labels