The config file reportserver.properties contains settings which are needed at ReportServer startup time as well as settings concerning cryptographic functionality. All properties are stored as attribute value pairs.
Excerpt from the reportserver.properties file
rs.crypto.pbe.passphrase = The Passphrase rs.crypto.pbe.keylength = 128
Passwords (such as, for example, datasource passwords ) that are stored in ReportServer will be encrypted. ReportServer uses AES and password based encryption. For this, you need to configure the following properties:
the salt that is used on key generation by the password based encryption method. This value should be set to a long random string.
The key size used. Keep in mind that key sizes over 128 require the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. For more information, see http://www.oracle.com/technetwork/java/javase/downloads/index.html.
For secure storage of user passwords ReportServer uses the salted HMAC construction.
Defines the static part of the salt for the salted HMAC construction. This value should be set to a long random string.
ReportServer supports several methods for user authentication. The different methods can also be combined.
This parameter defines which authentication methods are to be used. The individual values are separated by a colon.
The following authenticator modules are available
This is the standard mechanism and allows users to authenticate using a username and password. Note: with this authentication method username and password are sent to the server in the clear. Thus, this method should only be used over a secure channel (such as TLS/SSL). If you are not in a secured environment choose the ChallengeResponsePAM instead.
With this method you can restrict the set of IP addresses that can access ReportServer. The allowed address ranges are configured in rs.authenticator.iprestriction.addresses. The individual values are separated by a colon. Example: rs.authenticator.iprestriction.addresses = 127.0.0.1/32:192.168.1.0/24
This method will disable authentication and log in all users as root.
This method is similar to the UserPasswordPAM but the password is transmitted securely to the server. In cases where the connection is not secured via SSL this is the recommended authentication method. Note though, that this requires the client browser to perform cryptographic tasks which may be slow on non-up-to-date browsers.
If your organization uses x509 certificates, you can use this method to allow users to log in with their client certificates.
This parameter allows to enable debug mode for client certificate authentication.
Setting this to true disables direct access using the root user. This is recommended for production environments. Note that you can switch to the root user using sudo if you need to perform administrative tasks (and you have the corresponding privileges). Further information on sudo can be found in the administration guide.
Setting this to true installs base data if the database is empty, i.e. during a first run. This includes the audit log and other data.
If this property is set to true, scripting is completely disabled, so no scripts are run, including the onlogin and onstartup scripts. Thus, should you find yourself locked out of ReportServer, you can disable any scripts via this property. Since no scripts will be executed you can then login correctly to ReportServer.
You can completely disable the scheduler by setting this property to true. If the property is set to true both in reportserver.properties and the analogous property is also set to true in /fileserver/etc/scheduler/scheduler.cf, the property set in reportserver.properties is taken into account, while the one set in /fileserver/etc/scheduler/scheduler.cf is ignored. This allows you to completely avoid running scheduled jobs if you don't have the possibility to log in and disable the scheduler quickly enough before any jobs are being executed.
You can completely disable session renewal by setting this property to true. This may be necessary in some Single-Sign-On (SSO) scenarios.