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.

The system is based on the Java Authentication and Authorization Service (JAAS). You can set permissions for all types of users whether real people or processes, and control access to resources such as Web pages, documents, data, forums and templates. Permissions are controlled through a combination of users, groups, roles and ACLs in AdminCentral.

• Users
• Groups
• Roles
• ACLs
• Custom login forms

Users

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.

Groups

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.

Roles

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.

ACLs

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 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 workspaces, not in the Website workspace.
• Permission. Type of permission 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 resource being controlled.

For example, the following ACL rule 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	Selected and sub pages	/$
Ready only	Selected and sub pages	/siteA
Read/Write	Sub pages	/siteA/news

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.