Security
When you started Magnolia you were asked for login credentials. After typing user name and password you were brought to the Magnolia AdminCentral.
Magnolia comes with a sophisticated Access Management System, which allows to define access rights to all nodes (Web pages, Configuration pages, etc.). But there is also a little more behind the scene. Magnolia's GUI is multilingual.
The repository is based on a "virtual" address structure (nodes and properties) plus Persistence Managers which do the reading/writing of the content. This allows to define so called ACLs (Access Control List) on top of the "node" structure.
About Access Control Lists (ACL)
An Access Control List (ACL) is quite similar to *nix security settings. It defines access rights (read, write, deny) on a node or node tree. The power of ACLs is in the combination of access rights entities. An example:
| Permission | Path |
|---|---|
| deny | /* |
| read | /projA |
| read/write | /projA/news |
In this example we "deny" (or "close") access to the complete website, then "allow" (or "open") "read" of /projA and "allow" "read/write" of /projA/news.
This Author will see /projA with all child pages, but can only edit pages starting in /projA/news.null
Magnolia Security Settings
Magnolia allows you to define ACLs and assign them to users or groups. The power lies in combining these three configuration settings.
Typically you would define groups and assign one or more roles (ACLs) to these groups. Then you would define the users and assign them to one or more groups. The users will inherit the access rights from their assigned group(s).
User
A user setting defines the login credentials plus some personal settings to identify a person accessing Magnolia and grant/deny rights. Rights are defined by roles.Group
Users with similar privileges are grouped together. The group setting is like a "parent" to its assigned users. The purpose is to define settings for one group rather than each individual user. Access rights defined for a group are inherited by its users.Roles
A role is basically an ACL. Magnolia allows to define different ACLs for one Role, one ACL per repository. An ACL can have one or more read/write/deny entities. The following pages describe Users, Groups and Roles in more detail.Magnolia's standard Repositories
Magnolia does not just configure one repository for all settings/configurations/website, etc. Magnolia structured the types of content into different repositories. Magnolia allows you to configure additional repositories with additional workspaces and Persistence Managers. These are the repositories which are configured by default:| Repository | Description |
|---|---|
| website | All pages added in the Website module are stored in the "website" repository. |
| config | The "config" repository stores all configuration settings of the Configuration module |
| users | Stores all the users added in the Security/Users module |
| usergroups | Stores all groups added in the Security/Groups module |
| userroles | Stores all roles added in the Security/Roles module |
| dms | All the (multimedia) documents added in the Documents module are stored in the "dms" repository. |
| packages | Magnolia packages created with the Packages tool will be stored in the "packages" repository. |
| mgnlVersion | An internally used repository to store all Versions of content pages and properties. |
| mgnlSystem | Internally used for Magnolia system values. |
| Store | Internally used for Workflow settings |
| Expressions | Internally used for Expressions defined in the Enterprise Edition and Workflow |