Security in Magnolia 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, set in the Config app.

Security in the Java Content Repository

Magnolia uses the Jackrabbit reference implementation of the Java Content Repository (JCR) 2.0 standard. ACL checks are performed at the JCR level. This low-level checking has the following benefits:

  • Better performance than checking in the application code.
  • Repository can be exposed to third party apps. Access Control Lists (ACLs) still apply.
  • Use JCR API directly without needing to wrap objects.

Internal security

Internal security is based on the Java Authentication and Authorization Service (JAAS). User permissions are assigned and managed in the form of ACLs via roles assigned to the users. Security can be configured either for URIs that a user is allowed (or denied) to access or on a more granular level via ACLs bound directly to the content in repository. User permissions are then checked on each manipulation of content by the user. This includes checking permissions on searches and making sure that the user cannot find the content that they have not been granted access to. Permissions are controlled through a combination of UsersGroupsRoles and ACLs in the Security app.

External security

External security is achieved via servlet container features. The strength of the security depends on the container used to run Magnolia. To improve the security, Magnolia recommends that you run Apache Web Server or another proxy server in front of the application server.

To minimize the risk of attacks on user accounts on a public instance, best practice is to limit user accounts to the required number and type. There are two basic solutions to limit the user account data needed by public instances:

  • Workflow: For workflow, the only mandatory user account is the superuser account. Once this account is set up, you can add other accounts as needed. See Workflow.
  • IP solution: Disable external access to AdminCentral (URIs starting with ./magnolia) from public IP addresses. Then specify the IP addresses from which users should have permission to log into AdminCentral. See IP and HTTP permissions.

Content security

Since content and templates are usually customized or completely developed by the users of Magnolia, it is the responsibility of users to ensure that developed content is not exploitable by cross-site scripting, HTML injection or similar attacks. For templates provided with Magnolia, the system tries to ensure there are no such vulnerabilities.

In addition to supporting standard templating with JSP, Magnolia also offers and recommends Freemarker as an alternative templating language. While syntactically similar to JSP, Freemarker tends to be less vulnerable to such attacks due to the fact that it does not permit inline execution of the code. Freemarker also provides various built-in HTML and JavaScript escaping functions which make it easy to ensure that templates do not suffer from the vulnerabilities mentioned above. In case of any concerns regarding the security, Magnolia Support treats all security related issues with the highest possible urgency and will always try to provide client with the workaround or temporary fix for the issues should there be any.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))