4.11. 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.11.1. URL Whitelist

Certain operations, e.g. redirect, are not allowed for external URLs. If you need to allow a URL you can add it to the whitelist in the /fileserver/etc/security/whitelist.cf configuration file.

	<urls>
		<url>http://www.host.com</url>
	</urls>
4.11.2. Configuring error message level of detail

Further, in this configuration file, you can select the level of detail of error messages shown to the user. Currently, the following is supported:

  • hideViolatedSecurityExceptionDetails When a security rule is violated, e.g. when a user tries to execute a report the user is not allowed to, specific details of the security violation are being printed to the user by default. This includes the specific security target, the rights/permissions being violated, the objects and the method where this happens, if available. This helps administrators to exactly understand which rights/permissions are needed for a specific object to be accessed by a user. If not desired, you can set this to false in order to hide these specific details from the user, which may be preferable in some cases. Defaults to false.

Below you can see an example configuration.

   <errorMessages>
      <hideViolatedSecurityExceptionDetails>false</hideViolatedSecurityExceptionDetails>
   </errorMessages>
4.11.3. 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.11.4. 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.11.5. Notifications

Users can be notified when their password has been created the first time or when their password was changed (by an administrator). The notification is done via email (note that for this the mail server must be correctly configured). For this purpose, the following configuration file is available: security/notifications.cf.

This configuration file allows to configure the texts sent by email and further allows to disable this functionality, if desired.

<createdpassword disabled="false">
	<email>
		<subject>Email Subject</subject>
		<text>Email Text
			Username: ${user.getUsername()}
		</text>
    </email>    
</createdpassword>
<changedpassword disabled="false">
	<email>
		<subject>Email Subject</subject>
		<text>Email Text
			Username: ${user.getUsername()}
		</text>
	</email>    
</changedpassword>

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

Further, this file allows to configure the texts of the email sent by the listlogfiles terminal command using the -e option.

<logfiles>
	<email>
		<subject>Email Subject</subject>
		<text>Email Text
			Filter: ${filter}
		</text>
	</email> 
</logfiles>

In this section, the following substitutions are available. For more information, check the listlogfiles documentation.

Expression Description
${filter} filter passed with -f parameter
${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
Note that from RS 3.3.0 the old lostpassword.cf configuration file is no longer available. This configuration is now done in the new notifications.cf file.
4.11.6. 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.11.7. 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 or $generated and disable it with disabled.