Trusting custom content in the Spotfire environment
Many Spotfire users want to extend the Spotfire environment in different ways. It has for a long time been possible to add scripts based on IronPython or JavaScript to analyses, to be executed through buttons in text areas or via actions based on clicks in certain visualizations, and you can also configure actions that interact with external systems. Further enhancements can be made using many different types of data functions that can either be created directly in an analysis file or saved as a separate entity in the Spotfire library. It is easy to add custom visualizations with the concept of visualization mods, and from Spotfire 14.4 and forward, you can also add scripts to be used by actions in action mods. 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.
Spotfire visualization mods, action mods and external actions
Spotfire visualization mods and action mods can be created and also uploaded to the Spotfire library by any user with sufficient privileges, and, similarly, an action that can potentially send data or interact with an external system can be configured by users with sufficient privileges. The license features for handling visualization mods or external actions are found under the Spotfire Extensions and Spotfire Analyst license. To ensure that only trusted developers are allowed to add and execute code, there are many things you can do as an administrator.
Sign items
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 helps you 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. Use signing based on a CA certificate if you create mods that are intended to be shared with other organizations. External actions are tied to a specific analysis and are always signed with your Spotfire account.
When the Spotfire account is used to sign code, the Spotfire Server will act as a certificate authority and issue a certificate for the user (on demand only). The certificate will expire after a period of time, and then a new certificate will be issued, if the user still remains in the system. This means that a Spotfire account cannot be used to sign mods while offline. It also means that you might need to copy certificates from one system to another to keep user signatures valid, for example, if your company develops mods on one server and wants to use them on another server. See Moving certificates from one system to another for more information. See Spotfire Developer Documentation > Spotfire Package Builder for more information about signing mods while offline or with certificates from a CA.
This validation is done for error detection rather than for security
reasons. If the certificate chain contains any intermediate certificates, the
validation step requires that the Spotfire Server is running and connected to
the internet, so that the intermediate certificates can be fetched and the
certificate chain can be validated. If the root certificate is not imported to
the Spotfire Server, this verification will fail, and it will not be possible
to trust such items. However, it is possible to switch off the server-side
verification by setting the configuration property
security.code-trust.validate-uploaded-cert
to
false
.
Trust mods, actions, or signers
The trusting can be performed on an individual level by end users who have permission to trust items and signers but, as an administrator, you can also predefine trusted signers for groups in the Spotfire environment. See Adding trusted signers to a group for more information.
For an end user, it is possible to either trust all items added by a certain person, that is, to trust the signer, or to trust specific items only. Signers and items that have been trusted by an end user with trusting privileges can be reviewed on each user's My account page on the server. It is reached by clicking the username at the bottom left while being in the library or on any other server administration page, or from one of the clients by clicking View all trusted signers in the Manage trust dialog. Users with trust permission can download certificates or remove previously added trust decisions they have made.
As an administrator, you can also view all trusted signers and items for each user, under Users.
If a specific mod is trusted, 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. If the signer is trusted, instead of a specific mod, then all future mods or new versions of a mod from that signer will automatically be trusted.
Untrusted mods
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 (end users who do not have permission to trust cannot add untrusted mods at all). The more mods that have been pre-approved by the administrator, the fewer questions will be shown to the end users who try to add visualizations to their analyses.
Untrusted external actions
If an external action is added to an analysis, and the 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 the end user whether to trust the action and show which data will be affected by the action.
Remove trusted signers
You can always withdraw a previous decision to trust a certificate or a Spotfire user signature. See Removing trusted signers from a group for more information.
Invalidate signatures and revoke certificates
If a user account has been used to sign items that the user does not wish to be responsible for, each user can invalidate their own signatures from a specific time and up until now. This is done from the My account page of the user (if any signatures are available).
As an administrator, you can
invalidate another user's signatures using the
revoke-code-signing-certificate
command in the CLI. If
a user is suspected to try to add malicious mods on purpose, then you might
also want to remove the user from the system. A previously imported root
certificate, issued by a certificate authority (CA), can be removed using the
command
remove-code-signing-root-certificate
.
Other users will be informed that the item is signed by an invalid signature.
Block certificates, users or custom items
It is also possible to block certificates, users or specific items from being used at all. See Blocking certificates, users or custom items for more information.
CLI commands
For a complete list of the commands available for handling trust, see Code trust commands.
Trust for script written in IronPython, JavaScript or within data functions
Currently, there is no way to sign IronPython or JavaScript scripts or data functions. This means that all such entities will be seen as unsigned in all the user interfaces. By saving scripts in an action mod instead of just adding them in the analysis, when possible, you can make trusting and sharing of scripts easier for both administrators and other users.
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. See System groups and Spotfire extensions for more information.
End users who have access can still review and trust unsigned entities from the
dialog in the Spotfire installed client.Data Functions written in R
Spotfire has its own implementation of the R language, Spotfire® Enterprise Runtime for R (a/k/a TERR™), which is included in Spotfire applications. Spotfire Enterprise Runtime for R 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 makes 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 is prevented from running until it has been trusted.
- Adding trusted signers to a group
Developers who create custom items (visualization mods or action mods) can sign their code, either with their Spotfire account when logged in to a server, or with a certificate from a certificate authority (CA). Similarly, configurators of external actions sign their actions using their Spotfire account. You can add both users and certificates as trusted signers for a group, as described in this topic, to make the workflows for end users of the custom items easier. In most cases, it is preferred to add the trusted signers as high up in the group hierarchy as possible, to avoid duplicated work. - Removing trusted signers from a group
As an administrator, you can remove trusted signers from a group at any time. - Revoking or removing a server certificate
If there are suspicions that a user on the Spotfire Server has signed unsafe items, it is possible to revoke the user's certificates, which renders signatures invalid. This prevents other users from making a trust decision based on false premises. As an administrator, you have the option to revoke a specific certificate for a user or for all certificates from that user, from a certain point in time, using the commandrevoke-code-signing-certificate
. Previously imported root certificates, issued by a certificate authority (CA), can instead be removed using the commandremove-code-signing-root-certificate
. - Blocking certificates, users or custom items
Certificates issued from a certificate authority cannot be revoked in the same way as user certificates based on the username from the server. To prevent users on your system from being able to trust and use specific custom items or items signed by a specific certificate or user, it is possible to add the item, certificate or user to the blocked list. This is done using theblock-code-trust
command. Blocked items or custom items signed by a blocked certificate or user will never be executed. - Moving certificates from one system to another
If your company is developing and testing new custom functionality, such as visualization mods or action mods, in one system and want to keep signed items valid when moving them from test to production, you can do this by using theexport-code-signing-root-certificate
andimport-code-signing-certificate
commands. This way, the signatures made on another server will be treated as if they were signed with a certificate from a trusted certificate authority (CA). - Code entities and user roles
When setting up your Spotfire environment, you can specify that certain users or certificates should be trusted as signers in specific roles. One user might be trusted in the role of a developer, whereas another is trusted as configurator of external actions. - Configuring allowed issuers for code trust
When the certificate chain for a certificate is being verified by the Spotfire Server, a field in the Authority Information Access on the certificate is used to get hold of the issuing certificate. You can configure a list of URLs from which it is allowed to fetch certificates using thesecurity.code-trust.allowed-issuers
command. - Finding scripts in analyses in the library
Thefind-analysis-script
CLI command can be used to find all analyses containing scripts, data functions and custom queries and to list the content of all the scripts/functions/queries. This can be useful, for example, for trusting many scripts simultaneously or if an issue is discovered that must be found and fixed in all scripts.