This page gives an overview about how Magnolia handles security.
Overview: JAAS, users, groups, roles and permissions
Magnolia security is based on Java Authentication and Authorization Service (JAAS). JAAS provides a standardized way for:
Authentication: Reliably and securely determine who is using the system and provide them with means to sign into the application.
Authorization: Ensure that users have the permissions to do the actions required such as editing pages or creating categories.
The system always checks whether a certain user has the required (set of) permissions to access a certain resource such as a web page, document, template or some other type of data. Permissions such as Access Control Lists (ACLs) are assigned to user roles. The roles can be assigned to groups or directly to the users. Finally, users can be assigned to a group.
For more details please refer also to the following pages:
Magnolia Security app
Use the Magnolia Security app to
Groups and Roles with ACLs that
Magnolia provides. By default, the app stores the user, group and role
data in the
userroles JCR workspaces.
Web access security
Every request sent to Magnolia is checked by URISecurityFilter. The filter checks whether the role(s) of the requesting user allow(s) the user to request a given path with the given method.
Web permissions are granted as web access lists per role. They grant access to a path for Get or Get & Post.
Get – Grants the HTTP
GETmethod for a given URI.
Get & Post – Grants the HTTP
DELETEmethods for a given URI.
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 the need to wrap objects.
Since content and templates are usually customized or completely developed by the users of Magnolia, it is the responsibility of the 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 that there are no such vulnerabilities.
HTTP requests can be accessed either with
ctx.getRequest() (in templates) or with
info.magnolia.context.WebContext#getRequest (in code).
To prevent XSS exploits, the following HTTP request content is always escaped:
Parameters (names and values).
This policy, introduced with Magnolia 6.2.14, may potentially break code functionality or templates which rely on the original unescaped values.
Developers may unescape header values by using:
HTTP headers and security best practices
In this subsection, we provide some ideas how you can improve security through select HTTP headers.
Content Security Policy (CSP) header
You should list – as part of the header value – the origin and all the endpoints required for the page to function. However, if you allow any endpoint that is not within your control, you are opening a hole through which an attack might be staged. Therefore, be extra careful here.
If necessary, we recommend you customize the header to define your own whitelist.
Manually update the
Content-Security-Policyproperty value in the Configuration app.
An example final configuration could look similar to this:
Node name Value
default-src `self' `unsafe-inline' `unsafe-eval' https://ga-dev-tools.appspot.com https://apis.google.com https://www.google.com https://content.googleapis.com https://ajax.googleapis.com ; img-src `self' data:;
|The Vaadin framework performs the CSP check explicitly instead of relying on browser to do so as part of policy execution. You can see official Vaadin statement here.|
Strict-Transport-Security (STS) header
The STS header informs the browser that a page should only be accessed over the HTTPS protocol. The browser will use this knowledge and set all future requests for the same domain to go through HTTPS automatically, thus preventing the extra round trip that might be required otherwise.
Using HTTPS instead of HTTP enables traffic encryption between the page and the client, preventing anyone from intercepting the communication. Using this header is considered more secure than using the 301 redirect on the server when an attempt for the over-the-HTTP access is made.
X-Content-Type-Options (XCTO) header
XCTO is a marker header that tells the client that the media types (MIME types) advertized as part of the Content-Type headers should be strictly followed and not changed. This helps avoid MIME Type Sniffing.
X-Frame-Options (XFO) header
Setting the XFO header tells the browser that the given page is not allowed to be embedded in another page. This header setting helps mitigate stealing content, clickjacking (UI redress attack) or allowing malicious sites to pose as the regular ones and fool the users to not check the URLs closely but think instead that they are on a safe page when they are actually not.
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 the 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, limit user accounts to the required number and type.
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