Security Concerns

Depending where the site is hosted, anyone with a web browser can reach the site, and view it as an anonymous user. However, without a username and password, such visitors will not be able to view anything other than public pages. No content in the DMS will be visible to users not logged it, but some content in the KMS may be. That is, firms may select to make some content in the KMS visible to the world.

Without a Go-Between, visitors to the site will not be able to download any Working Papers client files. Allowing persons access to the OpenEngagement CMS through a web browser will not compromise the security of the content of the site, assuming no content is set Public in error. However, allowing persons access to the computer on which it is installed will compromise the security of the site.

For whichever computer the OpenEngagement DMS is installed on, you should assume that the any persons who have access to that computer, also have full access to the CMS. Anyone with access to the computer can start and stop the OpenEngagement CMS, add scripts to it or modify its source (given access to someone with knowledge of the python programming language, which is not an obscure language), install third party Plone products, etc. Given that most firms will wish to keep the OpenEngagement CMS very secure and free from tampering by tightly controlling access to it, and will also wish to ensure the OpenEngagement CMS is reliably running virtually all the time, this may be a serious concern. People with access to the computer on which the OpenEngagement CMS is installed will also be able to copy the OpenEngagement CMS database. With sufficient knowledge of Python, they could extract any information in the database. Also, users with access to the computer could install other applications, which could compromise the performance of the OpenEngagement DMS. That is, persons with access to the computer may also unintentionally affect the performance or reliability of the DMS.

Firms selecting the Local Solution option should, in most cases, severely restrict access to the computer on which the OpenEngagement DMS is installed. With the hosted solution, this is not an issue, as there is no access to the server by any firm member, and the only access to the OpenEngagement DMS is through a web browser, the Quick Upload, or the Go-Between.

Other Concerns Related to the Installation Location of the DMS

The OpenEngagement CMS can create a site that is public (internet/extranet) or private (intranet). There is no difference in the OpenEngagement CMS or how it is installed in these two cases. The difference is where it is installed, and how the firm controls access to it. A firm does, though, need to register the domain if they wish to make it an internet site. Note, if you do not register with any search engines, the site can still be found, and your site may receive some unwanted traffic.

Generally, the OpenEngagement CMS should be installed once per firm, but can be installed multiple times. If you install multiple times, you should ensure that different content is strictly kept within only one instance; if you wish to keep the same content in multiple locations, it is quite easy to run into versioning issues (not knowing which version is the most recent, most accurate etc.)

Installing the Go-Between

The Go-Between must be installed on whichever computers have Working Papers and where users will use Working Papers as an interface to the OpenEngagement DMS. There is an installer for the Go-Between, which is run for both Local and Hosted Solutions. There are no security issues related to the installation of the Go-Between.

The OpenEngagement DMS server has an installer for Windows platforms, which may be downloaded at any time from the OpenEngagement web site, http://www.openengagement.com. Look under Products, DMS, Downloads.

The installation process first installs Zope and Plone (web application platforms on which the CMS runs) and will then install the OpenEngagement CMS, which will include the DMS and KMS. 

IIS
It is not recommended that IIS run on the same server as the OpenEngagement DMS. Most Windows operating systems do not include IIS and those that do generally do not enable IIS by default. However, users should check that IIS is not installed and should remove it if necessary, using the Control Panel’s Add or Remove Programs. In this dialog, users may select the Add/Remove Windows Components button, and then remove Internet Information Services. If users do wish to run IIS and the OpenEngagement DMS on the same server, they must configure one to use a different port, as both use port 80 by default.

Port 80
As well as IIS, the server should have no other applications using port 8080 or 80, the ports used by default for Zope and HTTP respectively. To determine there are no other applications using these ports, a useful utility is TCPView, which is a freeware application available at www.sysinternals.com.

Restarting Windows
The installation process must restart Windows. Once restarted, the CMS server will be running and users can launch a web browser to access it.

Launching the OpenEngagement CMS
The OpenEngagement CMS is installed as a Windows service and should be running whenever the computer on which it is installed is running unless it is specifically stopped. To check the service is running, you may go to the Control Panel, Administrative Tools, Services, and check the status of the Zope service, and start it if necessary.

Accessing the OpenEngagement CMS Through a Web Browser
The OpenEngagement CMS may be accessed through a web browser, through the Quick Upload or through the Go-between. The URL will be: http://localhost/CMS. The DMS often takes a couple minutes to start up. You may wish to save this URL in your favourites. To use a web browser on the same computer on which the OpenEngagement is installed, you may always use this URL. To access it from other computers, you must specify the name of the computer in the URL. For example, if the computer is named Jupiter, you would specify: http://Jupiter/CMS.

Accessing the OpenEngagement CMS Through the Go-Between
The Go-Between is very tightly integrated with Working Papers, and will actually run inside your Working Papers application window, appearing as a series of menu items. The first steps are to install the Go-Between and then to configure Working Papers to work with the OpenEngagement DMS (The Go-Between does not interact with the KMS). This is generally a one-time operation, though users may change the settings for the OpenEngagement CMS from time to time. Configuration is done by going to Tools | Options | DMS and specifying OpenEngagement CMS as the current CMS, then hitting the Configure button. This brings up the configuration dialog where users specify the settings of OpenEngagement CMS. Unless you've changed the settings of the OpenEngagement CMS you should be able to use the default settings of 80 and blank for the Port and Path fields respectively. For the Server, you should set this to the same path as you use in a web browser, omitting the http:// portion. Once this is done, you will be able to access the Go-between through the Open from OpenEngagement and Save to OpenEngagement menu items.

Usernames and Passwords
Once your OpenEngagement server instance has been installed, likely your first task will be to create user accounts for the initial users of the system; later, additional users may be added or deleted as necessary at any time. You may assign some users site-wide roles, but most will likely be given only the Member role and assigned further roles locally.

The same set of usernames and passwords are used in the web browser interface, Quick Upload, and Go-between.

The installer will create two user accounts, one with user id admin and password admin, the other with user id script and password script. The admin user account should be used to create additional user accounts. Once these additional accounts are tested, the password for the admin account should be changed. The password for the script user account should also be changed. Doing this is described later in this documentation.

Setting Up Your OpenEngagement CMS Instance
Once the initial set of users is created, you will then create one or more Areas, as well as Entities and possibly Sections to organize your site. These tasks cannot be done through the Go-Between and must be done through a web browser or through Quick Upload. Within Areas you may create Entities and, optionally, sub-Areas or Sections. Within Entities, you may create Sections and, optionally, sub-Entities. Within Sections, you may create Engagement, Page, File, Link and Image objects. Engagement objects are intended to store compressed CaseWare client files. Once the general structure of your site has been created, and the initial content has been created, you should assign users local roles, so they may begin using the system and/or themselves assigning further users additional local roles. Firms may define the set of Sections that are created automatically within each Entity. Assuming a firm wishes to have the same set of Sections in each Entity, users should never need to explicitly create or delete Sections.

Email Server
Likely the most difficult step related to installing the OpenEngagement DMS is configuring the email server. This is done under Mail Settings, which is accessible from the Preferences link or using the URL, http://localhost/CMS/prefs_mailhost_form. Users should also define the site administrator email. This is done in the Portal Settings page, also accessible from the Preferences link, in the Site 'From' Address field. This may be tested by navigating to the contact page and sending an email. Ensure that the site administrator does receive this email.

For all sites, the following information must be provided before mailing will work:
- Portal Settings must contain a valid "From:" email address
- Mail Settings must contain the correct mail server and port.
- Any users wishing to contact the site must also have a valid e-mail addresses. Note, the admin user account does not have an associated email account, and so cannot send or receive email.

Firms may install an SMTP (email) server on the same computer where the DMS is installed, or may specify an already existing SMTP server elsewhere on the network.

Scheduled Tasks
The OpenEngagement DMS uses a number of scheduled tasks, which will be set up by the installer. To check these are created properly, users can go to the Scheduled Tasks dialog in the Control Panel. There should be four scheduled tasks installed by OpenEngagement. These should each run every day overnight and should create a log file in the bin directory called script.log.

The hardware requirements for a server hosting the OpenEngagement DMS are the same as for hosting any other Plone-based product, and so this section quotes Plone experts discussing requirements for Plone. As with any Plone-based product, there are certain minimum requirements, but the specific requirements will be based on the volume of data stored and the volume of traffic.

The OpenEngagement DMS may be installed on Windows XP, Windows 2000, Windows 2003, OpenBSD, FreeBSD, Linux, and OS X. However, the installer will only run on Windows platforms. With Windows systems, a server operating system is recommended, since non-server operating systems limit the number of simultaneous connections which may be made with the server.

From Andy McKay’s The Definitive Guide To Plone:
"For a Plone server, a high-performance computer will obviously make Plone perform better. Plone is a complicated system that requires processing power and memory. In general, it's recommended you don't go into production with a machine slower than 2GHz with less than 1GB of Random Access Memory (RAM) if you're serving a large Web site. It works fine with setups as low as 500MHz and 64MB of memory for more modest sites, however. For a base installation of Plone, you'll need about 50MB of hard drive space. If you already have installations of Zope or Python, then this will be a great deal less; you'll need about 2MB. You must also account for the Plone object database, which can grow to almost any size depending upon the amount of data you store."

With the OpenEngagement DMS, the major parameter affecting performance is RAM. The OpenEngagement DMS can run with as little as 512 MB of RAM, but the more the better. 2GB of RAM is ideal. The hard drive disk space required is based almost entirely on the combined size of the documents the firm anticipates uploading to the DMS. As a rough means to estimate the hard drive spaces required, firms may estimate the combined size of the documents and double this.

Users should also arrange for full backups to a separate hard-drive.

Firms with hundreds of users may and firms with thousands of users will likely need to utilize multiple servers in order to ensure the DMS is responsive. For this, we recommend using ZEO technology and a load balancing application such as Pound. However, some firms even with thousands of users may not generate enough traffic to necessitate this, particularly where high end hardware is used.

Once installed, the firm should change the password for the admin user account. Without doing this, anyone with access to the site can quite easily log in as the administrator, and as such may at any time, delete, modify or view data they should not. The default administrator password is documented and very easy to guess. Once changed, it should be given to very few individuals, preferably only one. Firms may wish to give the password to more than one user in case this person leaves the firm or is unable to pass it on to others.

To change the administrator password, log on as the administrator and navigate to the ZMI. This should have a URL in the form of: http://yourserver:8080/manage

Click on acl_users on the left side of the screen. (ACL stands for Access Control List.) In the main window click on users. One user listed should be admin. Click on the Password link and enter a new password. Once this is done, check the new password works properly.

The password for the script user account may be changed as well. Doing this is less necessary, as the script user account can do nothing other than run the overnight scripts. Nevertheless, some firms may wish to change this password as well. To do so, users will also have to change the password used in the scheduled tasks.