4.9. Security related properties

In the following section we describe certain security related configuration options.

In /fileserver/etc/security/misc.cf you can define a blacklist for ReportServer expressions. If not running ReportServer with a SecurityManager, you should ensure that such expressions cannot use java reflection. At a minimum level you should deny the phrase getClass. Further information can be found in the administration and user guides.

	<juel>
		<expression>
			<blacklist>getClass</blacklist>
		</expression>
	</juel>

In the example the expression getClass is prohibited. Multiple expressions are comma separated.

4.9.1. Configuring cryptography

The file /fileserver/etc/security/crypto.cf defines various cryptography related options. The <cryptocredentials> section defines how cryptographic credentials, such as private keys and certificates are retrieved for various ReportServer modules.

To do so, a provider is specified for each module.

A provider is defined by specifying the name of the handler-class and some additional attributes.

	<provider type="signature">
		<class>
			net.datenwerke.rs.incubator.service.crypto.FileServerKeyStoreKryptoCredentialProvider
		</class>
		<alias>rs</alias>
		<secret>secret</secret>
		<type>jks</type>
		<location>/fileserver/keystore.jks</location>
	</provider>

This configures the default handler, which tries to load key-material from a file within the fileserver. Providers can be specified for these types:

signature: a keystore that holds the private key, ReportServer uses when sending signed emails

user: a keystore that holds public keys and certificates of ReportServer users. This is used, when sending encrypted emails. An alternate method to provide key material is by using a custom script, that retrieves the keys e.g. from a corporate directory.

4.9.2. Specifying a Password Policy

ReportServer allows to configure the use of password policies to ensure that users choose secure passwords. The corresponding configuration goes into the configuration file /fileserver/etc/security/passwordpolicy.cf.

For example, you can define how long passwords should be and define character classes from which the password must be built. Furthermore, you can define how often passwords need to be changed and when a previously chosen password may be chosen again.

	<pswd>
		<maxage>32</maxage>
		<minage>1</minage>
		<minlength>8</minlength>
	</pswd>

The parameter maxage defines the number of days a password remains valid. The parameter minage denotes that a password may be changed at most every day. Minlength defines the minimal length of passwords.

The property <historysize>6</historysize> denotes that the last 6 passwords may not be used when changing the password.

You can define a threshold on the number of failed login attempts after which a user account is blocked. This is done using <lockoutthreshold>3</lockoutthreshold>. <lockoutresettimeout> 60</lockoutresettimeout> specifies the time after wich automatically locked accounts can be used again.

The <characterset> definitions specify which characters for a password are approved and how many characters from a particular group must be used.

	<characterset>0123456789</characterset>
	<choosemin>2</choosemin>
	<characterset>abcdefghijklmnopqrstuvwxyz</characterset>
	<choosemin>1</choosemin>
	<characterset>ABCDEFGHIJKLMNOPQRSTUVWXYZ</characterset>
	<choosemin>1</choosemin>
	<characterset>!$
	<choosemin>2</choosemin>

In the above example, it is specified that from the first and last group (the digits and special characters) at least 2 characters must be used. From the two remaining groups at least a single character must be used.

Note that the specified number denotes a lower bound on the characters chosen from this group.

A complete configuration of the password policy might thus look as follows:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<rs>
		<security>
			<passwordpolicy>
				<bsipasswordpolicy>
					<pswd>
						<maxage>32000</maxage>
						<minage>1</minage>
						<minlength>8</minlength>
					</pswd>
					<historysize>6</historysize>
					<lockoutthreshold>3</lockoutthreshold>
					<lockoutresettimeout>60</lockoutresettimeout>
					<characterset>0123456789</characterset>
					<choosemin>1</choosemin>
					<characterset>abcdefghijklmnopqrstuvwxyz</characterset>
					<choosemin>1</choosemin>
					<characterset>ABCDEFGHIJKLMNOPQRSTUVWXYZ</characterset>
					<choosemin>1</choosemin>
					<characterset>!$
					<choosemin>1</choosemin>
				</bsipasswordpolicy>
			</passwordpolicy>
		</security>
	</rs>
</configuration>
4.9.3. User activation

Users can be activated by administrators using the user manager. On activation, the user will receive an email with an automatically generated (single use) password (note that for this the mail server must be correctly configured). After the first login, the user must change the password according to the password policy.

You can customize the email sent to the user in the configuration file /fileserver/etc/security/activateuser.cf.

	<security>
		<activateaccount>
			<email>
				<subject>Your ReportServer account details</subject>
				<text>
					Username: ${user.getUsername()}
					Password: ${password}
				</text>
			</email>
		</activateaccount>
	</security>

The following substitutions are available.

Expression Description
${user.getUsername()} username
${user.getFirstname()} user's first name
${user.getLastname()} Last name of user
${user.getEmail()} user's email address
${user.getTitle()} user's title
${user.getId()} user's id
${password} the generated password
${url} the URL under which ReportServer can be accessed
4.9.4. Configuring the SFTP Server

ReportServer Enterprise Edition can be configured to expose its internal filesystem (and other management areas) using an SFTP server. The corresponding configuration goes into /fileserver/etc/misc/misc.cf.

	<remoteaccess>
		<sftp disabled="false">
		    <!-- Use $generated in order to generate a key on first start. -->
			<keylocation>/path/to/hostkey.pem</keylocation>
			<port>8022</port>
		</sftp>
	</remoteaccess>

The SFTP server can be disabled if you don't need it via the disabled property. After a ReportServer restart, it will not be started if disabled previously.

The file hostkey.pem should contain the server's certificate. You can also use $generated in order to generate a key on first start. The path should be an absolute path (e.g., file:///C:/path/to/hostkey.pem in Windows or /path/to/hostkey.pem in Unix.) Note that the file:// protocol is necessary in Windows in order to recognize C as the beginning of an absolute path.

Note that changes will only take effect after restarting ReportServer. If you do not want to start the SFTP server simply supply an invalid path.