Security is controlled with a built-in access management system. The purpose of this system is to:
- Authenticate. Reliably and securely determine who is using the system and provide them with means to sign into the application.
- Authorize. Ensure that users have the permissions to do the actions required such as editing pages or creating categories.
A user is an account that identifies the person accessing Magnolia CMS. In addition to a username, the system stores the user's full name, password, language preference and email address by default. Users inherit their permissions from the groups and roles they are attached to. Users are organized as follows:
- Users can have both roles and groups.
- Groups can have groups and roles.
- Roles can have only ACLs.
Permissions are defined in the ACL. Users inherit permissions from the roles and groups assigned to them.
In a small site you can manage users and groups in Magnolia CMS. On a larger site (hundreds of users) it is better to manage users and groups in an enterprise-grade user directory such as LDAP. You would define roles and ACLs in Magnolia CMS but manage users and groups in the external system. Magnolia CMS supports directories via the LDAP Connector, a standard JAAS login module.
Users with similar privileges are grouped together. The purpose of a group is to define settings for the group as a whole rather than each individual user. Permissions that apply to the group are inherited by its users. By assigning a role to a group, all users in the group will inherit the permissions granted to the role.
A role is a function a user performs in the management of a Magnolia CMS 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 role Publisher on the other hand is tasked with reviewing content and publishing it from the authoring instance to public instances. Note that role names and permissions are completely configurable to match your actual requirements.
The standard installation of Magnolia CMS includes default definitions of roles, groups and users. A sample structure is provided to demonstrate a typical setup, and it can be adapted.
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.
Example of ACL rules defining permissions to access a site:
An ACL rule defines:
- Controlled space. ACL rules are defined per controlled space, for example
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 nodepermission is only available in
Expressionsworkspaces, not in the
- Permission. Type of permission applied to the controlled resource, for example
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 resource being controlled.
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
|Deny||Selected and sub pages||
|Ready only||Selected and sub pages||
For technical reasons you can only select "Selected and subpages" or "Subpages" scope in the
website workspace, not "Selected page only". When you need to restrict user access to just the root node (
/), use the dollar character (
$). The dollar character means "end the expression here". It allows the user to expand the site tree in AdminCentral. Then create further rules to grant explicit access to paths (
/siteA) the user should be able to access.
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.
Custom login forms
You can configure your own login form in the
uriSecurity filter to replace the default Magnolia CMS login form. The form is configured in Configuration >
/server/filters/securityCallback/clientCallbacks. Here you find an example of a custom form used to grant public users access to a restricted members' area. Authentication is delegated to the custom form when a particular URL is accessed.
If you don't give permission to the custom login form path then the standard Magnolia CMS login form will be displayed instead (usually on author instance).