Security
This page provides a list of hardening measures to improve the security of your Magnolia setup.
Underlying technologies
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, refer to:
JCR
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 check 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.
| Resources on classpath should not contain sensitive information (for example passwords or api keys) as this type of information could be exposed via the Resource Files app. |
Filters
Web access
Every request sent to Magnolia is checked by info.magnolia.cms.security.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
GET,PUT,POST, andDELETEmethods for a given URI.
Cross-site security
The cross-site security filter is executed in the Magnolia filter chain before the URI security filter. A user must pass the cross-site filter before authentication or authorization through ACLs. The cross-site filter allows or denies permission to a site based on its domain name. For more information, see Cross-site security
Authentication and permissions for modules and apps
Magnolia Security app
Use the Magnolia Security app to administer users groups, and roles with ACLs that Magnolia provides.
By default, the app stores the user, group and role data in the users, usergroups, and userroles JCR workspaces.
Authentication
Magnolia also provides connectors to integrate with third-party systems.
- CAS module
CAS module enables Central Authentication Service (CAS) in Magnolia. CAS is a single sign-on (SSO) Web protocol that permits a user to log in once to a system and then automatically gain access to all related systems to which they have been granted permission as per their credentials. This avoids the need to log into each system individually. The Magnolia CAS module handles authentication only. When a user logs into CAS, the system authenticates their identity to participating services because the user has been authenticated to CAS.
- LDAP module
LDAP Connector module is a JAAS login module that connects to any LDAP v3 directory service. The LDAP Connector is used in intranet environments where an enterprise user management infrastructure already exists. With JAAS you can meet single sign-on requirements or connect to legacy LDAP servers.
|
The best practice is to reduce the number of user groups in Magnolia. Create a matching group for each LDAP group and configure group roles for necessary permissions. For more information, see Group resolving. |
- SSO module
-
The Magnolia SSO (single sign-on) module delegates authentication from a Magnolia instance to an OpenID Connect identity and access management application. The current iteration of the module has been successfully tested with open source Keycloak and cloud identity management software Okta, but all providers that follow the protocol should also be supported.
As Magnolia is already capable of full-fledged security, the intent is to only replace the authentication mechanism. A user on a third-party system with roles and groups is mapped to the equivalent Magnolia user roles and groups.
App permissions
Provision apps only to users who need them, following the Principle of Least Privilege (PoLP). Each user should only have access to the resources necessary for their role, and no more. For more information, see App permissions.
Content
| Since content and templates are usually customized or completely developed by the users of Magnolia, it is your responsibility 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. |
FreeMarker provides various built-in HTML and JavaScript escaping functions to ensure that templates don’t suffer from the vulnerabilities mentioned above. In case of concerns regarding security, Magnolia Support treats all security-related issues with the highest possible urgency and always tries to provide customers with a workaround or temporary fix for any issues.
HTTP requests
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:
-
Header values.
-
Cookie values.
-
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
Content Security Policy governs what a web browser (or a user agent, in general) is allowed to load as part of a page. Setting a CSP header allows the creator of a page to control what other resources might be loaded by the underlying HTML or JavaScript code. This is a powerful way to mitigate many Cross-site scripting (XSS) attacks.
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.
-
Create a new filter manually in the Configuration app and add the
Content-Security-Policyproperty under it. -
An example configuration could look similar to the one below. The path
server/filters/HeaderFilterOneis only a suggestion. When adding CSP headers, you only need to place the header values into theContent-Security-Policyproperty.📁 server
📁 filters
📁 HeaderFilterOne
⬩ class
info.magnolia.cms.filters.AddHeadersFilter
⬩ enabled
true
📁 headers
⬩ Content-Security-Policy
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. |
See also:
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.
See also:
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.
See also:
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.
See also:
REST requests
Endpoints always require URI access. They may also require JCR access or a specific role defined at a command level. The REST module itself installs four default roles.
Publishing
The publishing authentication mechanism requires no configuration. The first time content is published, it automatically generates the public key, which is then transferred to the public instance.
You can define trusted publishing receivers in /server/activation/receiversWhitelist and the whitelisting feature is turned off by default. If you use a light module to configure receivers, it is necessary to define trusted publishing receivers.
Policies
When it comes to ensuring a secure platform, there are a few things you need to keep in mind. You’ll want to take steps to minimize risks, follow established standards, and proactively manage any vulnerabilities or security issues that may arise. Doing so can help ensure that your platform stays safe and secure for all users. For more information, see Security policy.
A short checklist of important security considerations is summed up in Best practices for a secure Magnolia environment.
External security
External security is achieved via servlet container features. The strength of security depends on the container used to run Magnolia. To improve 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 permissions.