This chapter provides tips for securing the EDQ environment.
The chapter includes the following sections:
A limit can be specified in login.properties for the number of concurrent logins by an individual user. This can be configured either globally or on a per realm basis.
To set this globally for all realms, use the following line:
sessionlimit = 1
To use different settings for different realms, specify the realm name before the parameter - for example:
internal.sessionlimit = 1
Note:
Using the line given above, you can also limit the concurrent logins in an `internal' realm, meaning the users set up and administered in EDQ itself.<external realm name>.sessionlimit = 1
Where it is not needed, FTP/SFTP access to EDQ should be disabled for optimum security. Standard FTP can be disabled by adding the following line in director.properties within the configuration folder:
launch.ftpserver = 0
SFTP/SCP can be disabled using the following line within the same file:
launch.sshd = 0
If non-admin users are allowed access to FTP/SFTP, it is advisable to remove access to the configuration folder from the SFTP server, as follows:
Create the folders extras/ftpserver/conf and extras/sshd/conf within oedq.local.home, if they do not already exist.
Copy the files extras/ftpserver/conf/ftpserver.xml and extras/sshd/conf/sshd.xml from the oedq.home configuration directory to the corresponding subfolders of oedq.local.home.
In each of the two files from the previous stage, comment out the following lines:
<!-- Configuration area --> <ref bean="configspaces"/> <!-- Command areas --> <ref bean="commandspaces"/>
The first reference is to the configuration directories; the second is to the command areas used for external tasks.
Restart the application server. The only location visible to the FTP and SFTP servers is now the landing area.
When integrated with Siebel or other 3rd party components that call EDQ web services, an account with only the minimum permissions should be used. These are 'connect to messaging system' and permissions to the relevant project or projects containing the web services.
Unless specific steps are taken, a user in EDQ can set up a data store with a reference to the JNDI name and then access data in these schemas, which can contain very sensitive information. To protect JNDI data sources in EDQ, specify the names (or regular expressions matching the names) in director.properties:
protected.jndi.datasources = <space separated list of JNDI names>
For example:
protected.jndi.datasources = jdbc/edqconfig jdbc/edqresults
The property is a space-separated list of regexes so you could also use:
protected.jndi.datasources = jdbc/edq.*
The shared libraries (wingss.dll and libunuxgss.so) required for Kerberos integration are shipped inside the edq.war file. For most installations this is sufficient since EDQ can determine the location of the shared libraries and load the right version automatically.
However, this automatic loading does not work with all Java Runtime Environments (JREs), and notably it does not work with the IBM JRE. For these installations the libraries need to be extracted from the provided kerberos-gss.zip file and copied to a known location on disk. The location must then be added to the following environment variables such that the JRE can find it:
LD_LIBRARY_PATH (Linux, Solaris)
LIBPATH (AIX)
PATH (Windows)
Examine the native/Kerberos-gss.zip archived provided with the EDQ install and verify it contains the following files:
aix/ppc/libunixgss.a aix/ppc64/libunixgss.a linux/amd64/libunixgss.so linux/i386/libunixgss.so win32/amd64/wingss.dll win32/x86/wingss.dll
Extract the relevant library for the OS the EDQ server runs on, and copy it to a location on a disk accessible by the user EDQ runs as. This can either be part of the existing JRE classpath, or can be added to the environment variables mentioned above, so the JRE can find it.