Securing Web Central for Production Deployment
Securing Web Central for Production Deployment
Web Central is shipped as a WAR file. Out-of-the-box Web Central is configured for demonstration and development, and is not secure.
For production deployment, administrators need to secure Web Central.
Training and Demonstration: Archibus Authentication via afm_users
Archibus authentication via afm_users -- especially without password encryption -- is intended for training, demonstration, as well as application development and QA; it is not intended for production deployments.
Without password encryption, authentication via afm_users is not secure.
Production Deployment: SAML or OIDC WebCentral Configuration
For production deployments, SAML or OIDC WebCentral configuration is recommended.
Although afm_users configuration is not recommended for production deployments, if you do use afm_users configuration, you must encrypt all passwords. It still will not be as secure as SAML or OIDC, as Archibus authentication does not include all of the security features of IdP-focused providers, such as checking for password re-use. Security best practices are constantly changing and IdP-focused solutions are resourced specifically to stay most current on those.
Recommendations for Securing the Infrastructure
-
Optional: For highly secure environments, configure the SAML/OIDC Identity Provider for multi-factor identification. For example: Adaptive Multi-Factor Authentication | Okta
-
Optional: To prevent brute force attacks, integrate Google reCAPTCHA with their authentication solution: Google Recaptcha Single Sign-on (SSO) Integration
Importance | Recommendation | Description |
---|---|---|
High |
Configure your Web application server to use TLS (HTTPS) |
|
High |
Remove directory browsing permissions. |
https://tomcat.apache.org/tomcat-9.0-doc/default-servlet.html |
High |
Prevent search engine indexing. |
If your application server or Web server is outside your firewall, then keep search engines from indexing your deployment and any exported data, documents, or images. Do so regardless of whether or not you use HTTPS or remove directory browsing permissions. Do so even on application servers that are used only for demonstration purposes. To do so, set up robots.txt or configure HTTP server to use the X-Robots-Tag. See https://developers.google.com/webmasters/control-crawl-index/docs/robots_meta_tag. |
Medium | Secure Infrastructure |
Configure proxy server to add response headers: Strict-Transport-Security: max-age=63072000; includeSubDomains X-Content-Type-Options: nosniff Referrer-Policy: no-referrer Cache-Control: no-cache, no-store, must-revalidate X-XSS-Protection: 0 |
Medium |
Verify that your application server and JDK do not have known security issues. |
|
Medium |
Configure WebCentral cookies: secure, __HOST prefix. |
In web.xml: uncomment:
<cookie-config>
|
Low |
Consider using certificate security. |
If you want to authenticate non-domain users on the network (e.g. contractors or employees that log in via VPN), secure the Web Central server behind an authentication server using certificate authentication. See:
Configuring Smart Client for Windows Authentication
|
Low |
Use TLS 1.2 and above, and only use strong ciphers (AEAD ciphers). |
|
Low |
Disable TLS client-initiated renegotiation. |
|
Low |
Prevent services (Tomcat, Apache, OpenSSL) from disclosing their version numbers. |
https://www.techstacks.com/howto/suppress-server-identity-in-tomcat.html https://www.acunetix.com/blog/articles/configure-web-server-disclose-identity/ |
Low |
Use the latest supported Tomcat version. |
|
Low |
Implement a patching schedule to maintain up-to-date software. |
|
Low |
Prevent disclosure of internal IP address in error messages of SSO server. |
|
Low |
Configure SSO server to not produce debug output. |
|
Low | Consider using SSL for MS SQL Server database connection | remove “encrypt=false“ from “jdbc url” in afm-projects.xml |
Recommendations for Securing Web Central
Importance | Recommendation | Description |
---|---|---|
High | Restrict file system access to Web Central |
File system access for Web Central should be restricted to:
Delete the
|
High |
Remove default accounts. |
Web Central ships with default accounts in afm_users table. Delete the default accounts and establish your own accounts with your own names and passwords. Disable the GUEST account. Review the values in the \WEB-INF\config\security.properties file to ensure the system accounts do not use commonly-used names. |
High |
Configure database roles with unique user names and passwords. |
Configure database roles for each connection pool to use unique user names and passwords.
See:
|
High |
Disable editing view features except for authorized users. |
In the security.properties file, set the security groups for editing standard files and performing bulk change operations to the appropriate Security Groups used by your site. Doing so ensures that only appropriate users define new views or new schema elements. |
High |
Disable compatibility business logic rules. |
Set the Active? setting to No for
Verify that the
|
High |
Mobile client: encrypt SQLite database. |
Archibus provides an option for SQLite database to be encrypted using SQLCipher library. The configuration is enabled by setting the
|
High |
Encrypt passwords in configuration files. |
Encrypt passwords according to Encrypt Passwords in Configuration Files . |
Medium |
Disable unused services. |
If you are not using mobile apps, Connectors, or other services, disable these services. See Securing Archibus: Unused Web Central Services to Disable . For services that do not require broad access, consider deploying them on a different server. For instance, Connectors only need to be accessed by a local system administrator, and one or two other enterprise servers; they do not need general user access. Consider placing Connectors on a server that allows only local access, or access from specific IP addresses. Deploy a separate instance of Web Central to run scheduled WFRs only, and disable all other services. Deploy a separate instance of Web Central to serve only interactive users. |
Medium |
Establish a self-edit account policy. |
In the afm_users table, set Security Group restrictions on the afm_users table fields. Make only Navigation, Locale, Color Scheme, and User-Display Units-of-Measure editable by users, leaving all other values editable only by the Archibus Administrator. |
Medium |
Establish roles and groups. |
Establish security roles that correspond to the types of users and access in your organization (e.g. Archibus Administrator, Work Supervisor, Real EstateManager). Assign Security Groups to each role. Assign a role to each Archibus User. See also: Roles, Users, and Processes and Hierarchical Security |
Medium |
Establish business logic security. |
In the Archibus Workflow Rules table, assign each rule one of your Security Groups. Archibus will not allow a user to execute a rule unless their role allows them to. Archibus enforces this logic even if users invoke the logic from a copied view, an emailed view, or a reverse-engineered client-side file. To assign Security Groups to rules, you may wish to use the Smart Client row filter and Replace Column feature to update all fields of similar types in one step. You may also wish to use Archibus Hierarchical Security to nest domain and access requirements. See: |
Medium |
Establish data-level security. |
Assign a Review Group and an Edit Group to each Archibus data element in the Archibus data dictionary. To do so, you may wish to use the Smart Client row filter and Replace Column feature to update all fields of similar types in one step. You may also wish to use Archibus Hierarchical Security to nest domain and access requirements. See: |
Low |
Disable the same user account from logging in multiple times. |
Concurrent user accounts should always create a single session and sign out a single license, just as named user accounts do.
In
\web-inf\config\security.properties
, set
|
Low |
Review the list of file types WebCentral allows to upload and download. |
Review list of
Verify that any sensitive file types in this list (e.g. .zip files) are those that are scanned by your organization's anti-virus software. Do not include .html files in the list of supported file types. |
Low |
Assign only relevant work processes to each role. |
This limits forms and reports that each type of user sees. |
Low |
Define Virtual-Private Archibus data partitions. |
The Edit Group and Review Group settings on each data element in the Archibus data dictionary establish field-level access restrictions. Some sites prefer to also establish row-level permissions, such as to hide data from one site from users in another site. Doing so also prevents users who can define new views or change restrictions at the URL from accessing rows of data for which they do not have permissions. |
Low |
Enable URL Security for Views. |
Enable URL view-level security. This feature prevents users from loading any view from the URL address bar unless their role has rights to access that view from the Navigator. In this way, the site limits the views that can be loaded just through the normal administrative tasks that they use to place views on user menus. See: Archibus View-Level Security . |
Low |
Restrict loading of unassigned views. |
In
WEB-INF/config/security/properties,
modify
This increases start-up time from about 20 seconds to about 20 minutes. |
Low |
Remove WebCentral source code. |
Delete all Java files. Delete all unused files. Delete all highlighted folders and files:
Remove folders: /schema/ab-products/solutions |