The following article illustrates how the Eclipse Secure Storage works in Jaspersoft Studio and it presents some tips in order to better understand how to use it for saving sensitive information related to the Jaspersoft Studio environment.
Since Jaspersoft Studio is an Eclipse-based application, it relies on the underlying existing architecture coming from the Eclipse platform in order to provide the "secure storage" for sensitive information. Therefore it is highly advisable to read the related section in the Eclipse Help online guide: Workbench User Guide - Secure Storage.
Right now we are saving in encrypted format the following information, if the security option is activated:
- passwords for the all the Data Adapters that requires a typical user/password combination;
- passwords for the JasperReports Server connections;
- credentials for the Jaspersoft Community used inside the Bug/Issue Submission dialog.
Jaspersoft Studio Secure Storage
Jaspersoft Studio can be used as a standalone application or as Eclipse plug-in. Therefore it re-uses the Eclipse platform provided mechanism.
The secure storage saves data in an encrypted form. On some operating systems, it uses the user account information to provide a single sign-on experience (i.e: Windows and Mac OS X).
The secure storage itself does not contain encrypted code. It uses algorithms supplied by the Java virtual machine and/or the operating system.
Its preference page can be found under "General > Security > Secure Storage" after opening the Preferences dialog.
The master password used to encrypt data is obtained from a password provider module. The master passwords are obtained in a "lazy" fashion, only when they are about to be used. Password providers can use different techniques:
- on Windows, the master password is generated as a random value that is encrypted based on your Windows login information and stored in secure storage;
- on Mac OS X, the master password is initially created as a random value that is stored in the OS keyring. You can check using the Keychain Access utility;
- the default password provider simply prompts user for a password;
- other password providers might be supplied in the user application. In Jaspersoft Studio we don't do it.
When data is saved with secure storage, the password provider is selected based on the priorities from the list of enabled password providers. Only that provider can be used in future to decrypt the data.
By default, secure storage is located in the user home directory. Examples:
- Windows: C:\Users\mrabbi\.eclipse\org.eclipse.equinox.security
- Linux: /home/mrabbi/.eclipse/org.eclipse.equinox.security
- Mac OS X: /Users/mrabbi/.eclipse/org.eclipse.equinox.security
In this way different Eclipse-based applications are allowed to share the same secure storage.
In order to modify the location of the default secure storage, the user can specify the "-eclipse.keyring <file_path>" runtime option. The <file_path> is a path to the file which is used to persist the secure storage data, usually named secure_storage.
Solution 1: Clear Text passwords
The simplest approach, that would probably work fine for most of the users is to keep the passwords and credentials saved in plain text. After all this solution was the official one adopted by iReport and Jaspersoft Studio from the beginning.
After a specific request, the "Secure Storage" solution was adopted in order to provide the encryption to JSS/JR related credentials.
This feature however can be disabled/enabled from the Jaspersoft Studio dedicated preferences page. It can be accessed via "Jaspersoft Studio (Professional)>Preferences>Jaspersoft Studio>Global Settings" in Mac OS X or "Window>Preferences>Jaspersoft Studio>Global Settings" in Windows/Linux.
Leaving the option un-checked will make JSS work without interacting with the underlying Secure Storage. Passwords and credentials related to JSS/JR/JRS will be saved in clear text.
Solution 2: Secure Storage with OS integration
When enabling the usage of the "Secure Storage" feature for saving JSS/JR/JRS information you will end-up using the master password provider with the higher priority. In Jaspersoft Studio as in Eclipse, usually, the provider with higher priority is the dedicated-one that is tightly integrated with the underlying operating system. Therefore in Mac OS X you will have the "OS X Keystore Integration", while in Windows the "Windows Integration (32/64 bit)". In Linux there is no native integration available, so usually the only provider available is the so-called "UI Prompt". We will see in the next section what it is.
Mac OS X Secure Storage preference page
Windows 7 64-bit Secure Storage preference page
The OS integration is supposed to make the mechanism smoothly for you, in order not to bother with annoying pop-up dialog or confirmation ones. Only the first time you will save a credentials (i.e: a JDBC data adapter with password), you could notice the information about a new master password being created, with the chance to configure additional information for password recovery. See the two sample screenshots below:
Step 1: Ask for password recovery information settings.
Step 2: Questions/Answers for password recovery procedure.
However this kind of integration has proven to be quite fragile. Different issues and topics have been opened in both Bugzilla and in the Community Tracker (also Answers section).
Just an example here: Jaspersoft Studio Tracker Issue #3180
Since these kind of bugs are most likely Eclipse related, you can dig the Eclipse Bugzilla site for more info, it's something we can hardly fix. However there are alternatives that the final user interested in having a fully working "secure" solution can adopt. We will explain them in the next sections.
Solution 3: Secure Storage with UI Prompt
The UI Prompt is the alternative provider that is present in all platforms. It's a good choice to avoid the annoying problems that can be raised by the native integration. Moreover is the only option available in Linux.
In order to use it, you will have to disable the native integration if present (Windows and Mac OS X), and be sure that is the only one selected. See the Windows example below:
Enabling the UI Prompt in Windows 7 64-bit
In this way the first time you will have the need for storing sensitive information, a dialog like this will be proposed.
Creating the new master password for the UI Prompt provider
The password is usually cached through the application session, however you could end-up needing to enter the information (i.e: editing a JDBC data adapter after JSS startup). A similar dialog will be presented:
Dialog prompt for the master password of the UI Prompt provider
Since the appearing of a similar dialog can be sometime annoying, there is an advanced trick that can be used in order to avoid this behavior. See next section.
Solution 4: Bypass password provider mechanism with password file and dedicated keyring
The following solution will give to the user the chance to bypass the password provider mechanism specifying the "-eclipse.password <file_path>" runtime option. In this case the contents of the file specified as the argument will be used as a master password.
However in order to work smoothly this solution should be adopted together with the runtime option for a custom keyring. Please recall the following from the introductory section: "When data is saved with secure storage, the password provider is selected based on the priorities from the list of enabled password providers. Only that provider can be used in future to decrypt the data".
As usual these options can be specified inside the Jaspersoft Studio (Professional).ini configuration file, or even specified in the shortcut used to launch your JSS application.
Sample example in Mac OS X:
MassimoMac:MacOS mrabbi$ ./Jaspersoft\ Studio\ Professional -eclipse.keyring /Users/mrabbi/jss_keyring/ -eclipse.password /Users/mrabbi/jss_keyring/keyringpasswd
It worth noting the security issue that could be raised about the protection of the file containing the master password. Different strategies can be used in order to protect it, besides the classic operating system access rights. For example, the password file and even the keyring folder itself could be placed into an encrypted TrueCrypt volume.