Manage Trust

Many Spotfire users want to extend the Spotfire environment in different ways. When allowing custom code to run within an analysis, or when enabling direct interaction with other systems, it is important to consider security. Any custom item created by a malevolent person could potentially perform unexpected or undesired actions. Therefore, Spotfire uses different trust mechanisms to help you to keep your system safe.

In on-premises environments, administrators can control which users should be allowed to produce custom content, verified by licenses and group belonging, and trust can be predefined. If no predefined trust is available you will get a warning when custom items are used.

Note: All custom items that require some sort of trust can be inspected under File > Manage trust. You should only trust items if you are certain that they come from a reliable source.

Spotfire mods can be created and also uploaded to the Spotfire library by a user with sufficient privileges, and, similarly, an external action that can potentially send data or interact with an external system can be configured by users with sufficient privileges. An on-premises Spotfire administrator has access to many tools to ensure that only trusted developers or configurators are allowed to add and execute code, or to configure external actions. See the Spotfire Server and Environment - Installation and Administration guide for more information.

As an end user, you might have different options to trust items added by others, depending on your role in the environment.

Anyone who creates or adds a mod or an external action to the Spotfire environment can sign it. The signing informs other people about the origin of the item and makes it possible to make informed decisions regarding whether the item can be trusted or not. Signed items make it possible to verify the authenticity, integrity and publisher of the code or action.

Signing of mods can be done, either through certificates created by a certificate authority (CA), or automatically, using the Spotfire account of the person who loads a mod project to an analysis file. When you are offline, you can only sign mods using a certificate from a CA, not using a Spotfire account. See Spotfire Developer Documentation > Spotfire Package Builder for more information about signing mods using a certificate.

When a mod or external action is signed, it is easier to decide if you dare to trust it; that is, you base your trust in the company or person who has signed the item. It is possible to either trust all mods or external actions added by a certain person, that is, to trust the signer, or to trust specific items only.

If you trust a specific mod version, the mod will be seen as trusted in all analyses where it exists, however, re-trusting will be required if any changes are made to the mod at a later stage. An external action is always configured within the context of an analysis and will need to be reconfigured, and therefore signed again, if the analysis changes so that the configuration could lead to a data leak. If you decide to trust the signer, instead of a specific item, then all future items (or new versions of a mod) from that signer will automatically be trusted.

The trusting can be performed on an individual level by end users who have permission to trust items but an administrator can also define trust for a group of users in the Spotfire environment. To avoid unnecessary prompts regarding trust, the latter is often preferred, when possible.

Regardless if the mod is signed or not, attempts to add a mod that is not trusted to an analysis will lead to the question of whether or not it should be trusted (or, if you do not have permissions to trust, it cannot be added). Mods should only be trusted if you are certain that they come from a reliable source.

If an action is added to an analysis, and the mod developer or external action configurator has not been added as a trusted signer by the administrator, clicking on the trigger for the action in a visualization (for example, a floating button or the pop-up menu) will ask you whether you trust the action and, in the case of external actions, show you which data will be affected by the action.

Note: By default, only valid signatures can be trusted. In special cases, an administrator in an on-premises system can relax this limitation by changing a preference in Administration Manager (Application > Trust > Require valid signature to allow trust). Users running Spotfire Analyst without a server are always allowed to trust invalid signatures and should therefore be extra careful.

If you have the permission to trust signers and items you can also revoke trust you have added to an analysis using the File > Manage trust dialog. The View all trusted signers button in the dialog takes you to the My account page on the server, where you can get an overview of all trusted signers and items, and revoke trust that has not been assigned by the administrator. Note that an administrator can withdraw trust for something that you have trusted, or invalidate a user's signature at any time.

If your user account has been used to sign items that you do not wish to stand behind, you can invalidate all your signatures from a specific time and up until now. This is done from the My account page (if any signatures are available).

An administrator can also revoke the certificate for a signer to make a signature invalid, or block a signer or specific item, to prevent you from adding it.

IronPython and JavaScript scripts and data functions do not support signing, so those items are always shown under Unsigned items in the Manage trust dialog. Instead, Spotfire uses a trust mechanism, where users called Script Authors, verified by licenses and group membership, are the only ones that can make a script trusted for anyone in the organization.

Note: Most of the functionality described in this section only applies to on-premises solutions and to Spotfire Cloud Enterprise, not to the general TIBCO Cloud Spotfire solution. See also Usage of Scripts and Data Functions.

As a script author, you have the responsibility to provide other users in your company with secure and working scripts. When you have developed a data function or an analysis including a script you must make sure the script or data function is trusted before you save it to the library, to ensure that it can be used by others. You can review all scripts and data functions in an analysis and trust them one by one, or approve all your scripts in an analysis by selecting File > Manage trust and clicking Trust all.

If you need to edit the scripts before trusting them, go to File > Document properties > Scripts or Data > Data function properties where you can see an overview of all scripts and data functions, respectively.

By saving scripts in an action mod instead of just adding them with IronPython in the analysis, you can make trusting and sharing of scripts easier for both administrators and other users.

If you are an analysis author, there can be occasions when you want to run a script or data function that has not been approved and trusted by a script author. For example, you might receive a local file from a colleague for testing purposes.

If you open an analysis with untrusted scripts, you have the option to review and trust the scripts or data functions yourself, using the Manage trust dialog. If you need to edit the scripts before trusting them, go to File > Document properties > Scripts or Data > Data function properties where you can see an overview of all scripts and data functions, respectively.

If you are not the primary author of the script and you are not qualified to understand whether the script is safe, you should only trust it if you are certain that it comes from a reliable source.

Note: In some situations, you might need to reload data after a script or data function has been trusted to get the correct data.

In the web clients, it is not possible to assign trust to a script. If you encounter an analysis with untrusted scripts you must either open the analysis in the installed client and trust the scripts before saving the file, or contact a script author to do it for you.

Spotfire has its own implementation of the R language, Spotfire® Enterprise Runtime for R (a/k/a TERR™), which is included in Spotfire applications. TERR comes with a restricted mode which is built to provide a secure environment when working with data functions. If the data function is trusted, then it can be executed without any restrictions. If a TERR-based data function is not trusted, Spotfire will make an attempt to run the data function in the restricted mode. If the script uses statements that are not available in the restricted mode, then the data function will be prevented from running until it has been trusted.

Note: For inline TERR scripts (that is, when using TERR directly in custom expressions, only the restricted execution mode is available).

Note: If you have the Author Scripts license feature, but you are not a member of the Script Author group, you cannot run R scripts that you have created yourself (using Spotfire Analyst) when the Spotfire® Service for R is used. See also Usage of Scripts and Data Functions.