Learn recommendations and best practices for securing AEM Forms on OSGi server.
Securing a server environment is of paramount importance for an organization. This article describes recommendations and best practices for securing servers that run AEM Forms. This is not a comprehensive host-hardening document for your operating system. Instead, this article describes various security-hardening settings that you should implement to enhance the security of your deployed application. To ensure that the application servers stay secure, however, you should also implement security monitoring, detection, and response procedures in addition to recommendations provided in this article. The document also contains best practices and guidelines for securing PII (Personally Identifiable Information).
The article is intended for consultants, security specialists, systems architects, and IT professionals who are responsible for planning application or infrastructure development and deployment of AEM Forms. These roles include the following common roles:
The following image displays components and protocols that are used in a typical AEM Forms deployment, including the appropriate firewall topology:
AEM Forms is highly customizable and can work in many different environments. Some of the recommendations might not be applicable to your organization.
Transport layer security vulnerabilities are among the first threats to any Internet-facing or intranet-facing application server. This section describes the process of hardening hosts on the network against these vulnerabilities. It addresses network segmentation, Transmission Control Protocol/Internet Protocol (TCP/IP) stack hardening, and the use of firewalls for host protection.
An organization can have an external firewall to restrict access between an end-user and AEM Forms publish Farm. The organization can also have an internal firewall to limit access between a publish farm and other within organization elements (For example, author instance, processing instance, databases). Allow firewalls to enable access to a limited number of AEM Forms URLs for end-users and within organizations elements:
You can configure an external firewall to allow a certain AEM Forms URLs to access to the internet. Access to these URLs is required to fill or submit an adaptive form, HTML5, correspondence management letter or to login to an AEM Forms server:
|AEM Forms App||
You can configure the internal firewall to allow certain AEM Forms components (For example, author instance, processing instance, databases) to communicate with publish farm and other internal components mentioned in the topology diagram:
|Publish Farm (publish nodes)||/bin/receive|
|Forms Workflow add-on server (AEM Forms on JEE server)||/soap/sdk|
By default, assets available on the publish nodes are accessible to everyone. Read-only access is enabled for all the assets. It is required to enable anonymous access. If you plan to restrict form view and submit access only to authenticated users, then use a common group to allow only authenticated users to have read-only access to the assets available on the publish nodes. The following locations/directories contain forms assets which require hardening (read only access for authenticated users):
AEM Forms stores data to predefined locations and temporary folders. You should secure the data to prevent an unauthorized use.
When you configure forms for file attachments, verify, or preview components, corresponding data is stored on the publish nodes at /tmp/fd/. The data is purged periodically. You can modify the default data purge job to be more aggressive. To modify the job scheduled to purge data, open AEM Web Console, open AEM Forms Temporary Storage Cleaning Task, and modify the Cron expression.
In the above-mentioned scenarios, the data is saved only for authenticated users. Moreover, the data is protected with access control lists (ACLs). So, modifying the data purge is an additional step to securing information.
By default, forms portal submit action of adaptive forms saves data in the local repository of the publish node. The data is saved at /content/forms/fp. It is not recommended to store data on publish instance.
You can configure the storage service to send over-the-wire to the processing cluster without saving anything locally on the publish node. The processing cluster resides in a secure zone behind the private firewall and data remains safe.
Use the credentials of processing server for AEM DS settings service to post data from the publish node to the processing server. It is recommended to use credentials of a restricted non-administrative user with read-write access to repository of processing server. For more information, see Configuring storage services for drafts and submissions.
Use user accounts with minimum required privileges to configure data sources for form data model (FDM). Using administrative account can provide open access of metadata and schema entities to unauthorized users.
Data integration also provides methods to authorize FDM service requests. You can insert pre and post execution authorization mechanisms to validate a request. The service requests are generated while prefilling a form, submitting a form, and invoking services through a rule.
Pre-process authorization: You can use the pre-process authorization to validate authenticity of a request before executing it. You can use inputs, service and request details to allow or stop execution of the request. You can return a data integration exception OPERATION_ACCESS_DENIED if the execution is stopped. You can also modify client request before sending it for execution. For example, changing input and adding additional information.
Post-process authorization: You can use the post-process authorization to validate and control the results before returning the results to requester. You can also filter, prune, and insert additional data to results.
A different set of user personas are required for author, publish, and processing instances. Do not run any instance with administrator credentials.
On a publish instance:
On an author instance:
There are a different set of pre-defined groups with specific privileges for every persona. Assign users to group.
A user of forms-user group:
A user of forms-power-user group create, fill, publish, and submit all types of forms, write scripts for adaptive forms, import packages containing XDP.
A user of template-authors and template-power-user can preview and create a template.
A user of fdm-authors can create and modify a form data model.
A user of cm-user-agent group can create, preview, and publish correspondence management letters.
A user of workflow-editors group can create an inbox application and workflow model.
On processing author:
In general, Processing clusters and Forms Workflow add-on (AEM Forms on JEE) run behind a firewall. So, these are considered secure. You can still perform a few steps to harden these environments:
A processing cluster runs in the author mode but do not use it for development activities. Do not allow a normal user to be included in content-authors and form-users groups of a processing cluster.
This document provide instructions specific to AEM Forms environment. You should take to ensure that your underlying AEM installation is secure when deployed. For detailed instructions, see AEM Security Checklist documentation.