Skip to end of metadata
Go to start of metadata

Authentication

Authentication of iteraplan users is carried out using the Spring Security component of the Spring Framework. This permits connection of various data sources. With the default setting, users are authenticated by means of the iTURM database, which is made available by Tomcat via JNDI. You should therefore make sure that the right JDBC driver (for the database containing the authentication information) is located in the lib subdirectory of your Tomcat installation folder. If you want to use an existing LDAP directory (such as Active Directory) for authenticating users, refer to the detailed setup instructions.

Access via HTTPS Protocol

For reasons of security and data privacy, iteraplan should be configured to enforce access with the secure HTTPS protocol. The iteraplan installer offers you a choice which level of security you want to enforce. The use of the  HTTP protocol is inadvisable.

There are two ways of setting up HTTPS access that you can choose from. First, a web server such as Apache httpd can do the job of processing HTTPS requests and forwarding the decrypted requests to Tomcat. Please refer to the Apache httpd documentation for HTTPS/SSL configuration instructions, and to the Apache Tomcat documentation on the AJP connector for connecting Tomcat to Apache httpd.

Second, Tomcat also offers SSL-secured connections, i.e. HTTPS itself.

In order to use HTTPS it is necessary to install a server certificate (certificate keyfile) for the web server. The servlet engine also has to be configured for this protocol. iteraplan ships with the requisite server certificate – this is located in the folder prerequisites. If you do not intend to use existing certificates, you can create one with the keytool utility provided with Java. You run this utility as follows:

keytool
-genkey
-alias <server name> -keypass <password> -keystore .keystore
-storepass <password> -dname "CN=<server name>,
OU=<name of organisation unit >,
O=<name of organisation >,
L=<location>,
ST=<state>,
C=<country code, e.g. de>"

The resulting file .keystore then has to be copied to the conf folder in the Tomcat installation folder.

To instruct Tomcat to process HTTPS requests, you have to enter a connector in the file server.xml, which is located in the conf folder of your Tomcat installation folder. An example configuration is shown below:

<Connector executor="iteraplanThreadPool"
           protocol="HTTP/1.1"
           port="8443"
           acceptCount="100"
           disableUploadTimeout="true"
           maxHttpHeaderSize="65536"
           URIEncoding="UTF-8"
           enableLookups="false"
           scheme="https"
           secure="true"
           SSLEnabled="true"
           clientAuth="false"
           sslProtocol="TLS"
           keystoreFile="./conf/.keystore"
           keystorePass="Password" />

If you would like to use the .keystore file provided, enter the password iteraplan in the field keystorePass.

Further information to set up Tomcat for SSL can be found in the official Tomcat documentation:

Access via HTTP Protocol

If access via HTTP protocol is required, you have to make a small change to the iteraplan configuration: Open the file [iteraplan Server Context]/WEB-INF/web.xml and replace the section <security-constraint> ... </security-constraint> with the following:

<security-constraint>
   <web-resource-collection>
     <web-resource-name>Secured Area</web-resource-name>
     <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <user-data-constraint>
     <transport-guarantee>NONE</transport-guarantee>
   </user-data-constraint>
 </security-constraint>

In order to revert to the previous behaviour, replace NONE with CONFIDENTIAL.

Database cache

To improve the performance of the iteraplan application caches are used (via Hibernate and Ehcache). If the database has been modified outside of iteraplan, e.g. when a database dump was imported, the database and cache will be out of synchronisation. If this occurs, the cache must be cleared or the iteraplan application must be restarted.
To fine-tune performance you can adjust the time-to-live of elements in the cache configuration, see [iteraplan Server Context]/WEB-INF/classes/ehcache.xml

Connection Pooling

Connection pooling is a powerful way to improve performance. The default parameters work fine in most situations, but servers with a higher than normal workload may require additional tuning. At the moment iteraplan uses a DBCP connection pool, configured via a org.apache.commons.dbcp.BasicDataSource object. The configuration is made in the file [iteraplan Server Context]/WEB-INF/classes/iteraplan-db.properties. Here is a summary of the most important configuration options:

  • database.pool.autoCommit: specifies whether SQL statements should be auto committed by default (default: false)
  • database.pool.transactionIsolation: sets the default isolation level of the transactions
  • database.pool.initialSize: sets the initial number of connections to be created by the pool (default: 0)
  • database.pool.maxActive: limits the maximum number of active connections in the pool (default: 8)
  • database.pool.maxIdle / database.pool.minIdle: specifies the maximum/minimum number of idle connections permitted in the pool (default: 8/0)

Configuring Chrome or Chromium (server side)

Chrome or Chromium must be installed on the iteraplan server to enable the Shared Visualization feature.

Additionally a system property chrome_binary must be set in the Tomcat startup configuration, the value is the absolute path to the Chrome/Chromium executable:

...
CATALINA_OPTS="$CATALINA_OPTS -Dchrome_binary=/path/to/your/google-chrome"
...

Settings on different environments:

# If you use different version of Google Chrome like Chromium,
# then you must explicitly use the `chrome_binary` property.
-Dchrome_binary=/path/to/your/google-chrome

# e.g. For some Linux distribution
-Dchrome_binary=/usr/lib/chromium/chromium

# e.g. MacOS it may be something like
-Dchrome_binary=/Applications/Chromium.app/Contents/MacOS/Chromium
  • No labels