Publishing security

Publishing of content from author to public instances is authenticated using public-key cryptography. Public-key cryptography is a system that requires two separate keys: a public key to lock or encrypt the plain text request and a private key to unlock or decrypt the cyphertext request. Neither key can do both and neither is derivable from knowledge of the other. One is published and the other is kept private.

On receiving a publishing request, a Magnolia public instance authenticates the author instance using a public key. The author instance generates the key automatically on first publishing of content and transfers it to the public instance. You can generate new public keys any time on the author instance. A single public key is used for multiple public instances.

Configuration

The authentication mechanism requires no configuration. The public key is generated automatically on the first publishing of content and transferred to the public instance. The configuration of publishing is stored in the server:

Configuration of publishing stored in the server

The key pair is also stored on the local file system. If you use the default Magnolia bundle, the location is configured in a magnolia.properties file.

# Location of the file containing both the private and the public keys used to verify authenticity of activation requests
# This file is generated if not present magnolia.author.key.location=${magnolia.home}/WEB-INF/config/default/magnolia-activation-keypair.properties

Generating a new public key

You can create a new public key in the Publishing Tools app. A longer key means better security, but publications can take longer. The shortest key length already meets the standard security requirements.

To generate a new public key:

On the author instance, open the Publishing Tools app.
Click Generate new key. This generates a new public key and registers it automatically on the author instance.
Copy the new key from the Current public key box.
Sign in to the public instances and open the Configuration app.
Paste the key to Configuration > /server/activation/publicKey.

Copy the newly generated public key to all public instances. It’s not transferred automatically on publishing as is the case with the initial key. You can’t activate the publicKey node to the public instance as at this point because a mismatch exists between the keys on author and public.

Whitelist of publishing receivers

Any light module decoration can modify the configuration of receivers under /modules/publishing-core/config/receivers. If light module development is maliciously tampered with and you don’t have additional firewall settings to prevent outgoing connections, there is a risk of Server-Side Request Forgery (SSRF) attacks. To prevent this, you can provide a list of trusted publishing receivers in /server/activation/receiversWhitelist.

The receiversWhitelist can’t be modified by a light module. Only someone who has write access to the Configuration workspace in JCR can change it. The structure of subnodes is similar to the configuration of receivers, which allows you to use the JCR extends mechanism to provide basic protection by inheriting the JCR receivers' configuration. Follow the instructions in the next section to define trusted publishing receivers.

Defining trusted publishing receivers

The whitelisting feature is turned off by default. If you use a light module to configure receivers, you must define trusted publishing receivers. The steps to do this are outlined below.

Remove the url property with an http prefix (default configuration).
Define trusted publishing receivers using either or both of the options below.
- Provide a list of trusted receiver URLs, as shown below.
- Use a URL prefix if your receivers are on the same domain or have the same beginning.

When there are no security concerns regarding light module development, or you have configured firewall rules that prevent outgoing connections to unknown servers, you can use some prefix instead for the url property, e.g. http://, http or even an empty string.

Troubleshooting

Any type of misconfiguration related either to the keys themselves or the handshaking process between the author and the public instance(s) may lead to publishing errors.

Example:

SEVERE: Servlet.service() for servlet [default] in context with path [/magnoliaPublic] threw exception
org.bouncycastle.crypto.DataLengthException: input too large for RSA cipher.
    at org.bouncycastle.crypto.engines.RSACoreEngine.convertInput(Unknown Source)
    at org.bouncycastle.crypto.engines.RSABlindedEngine.processBlock(Unknown Source)
    at org.bouncycastle.jcajce.provider.asymmetric.rsa.CipherSpi.getOutput(Unknown Source)
    at org.bouncycastle.jcajce.provider.asymmetric.rsa.CipherSpi.engineDoFinal(Unknown Source)
    at javax.crypto.Cipher.doFinal(Cipher.java:2168)
    at info.magnolia.cms.security.SecurityUtil.decrypt(SecurityUtil.java:168)
    at info.magnolia.cms.security.SecurityUtil.decrypt(SecurityUtil.java:131)
    at info.magnolia.publishing.authentication.DefaultPrivatePublicKeyAuthenticator.authenticate(DefaultPrivatePublicKeyAuthenticator.java:92)