Secure Data Sharing with non-Holistics users by email

Feature Suggestions
,
#1

Overview

Add dashboard share feature so as a Dashboard creator I can share a dashboard to email-addresses, that don’t have a Holistics account, on a secure and scalable way.

End user experience

The feature should work as follows for the Dashboard consumer.

  • The Dashboard consumer receives an email with the link and a password for the dashboard
  • After clicking the link, the user gets redirected to a page where he puts in his email-address and password provided in the email
  • When viewing the Dashboard, the end-user should only see the data that is mapped to the provided email-address

Required setup for the Analyst

  1. Add email or user attribute to data. add a field in the dataset for each record, the email address or user attribute of the user that is allowed to see the record.
  2. If more than one user should be allowed to see the same record, user-attributes for external users should be setup. This would be done in the user management page, in a New seperate tab that covers only non-Holistics users.
  3. The final step is to send out the Dashboard by following these steps:
  • Go to the dashboard that you want to share, and click on share link with credential access
  • Fill in the email of the recipiënt, where by default the Dashboard is secured with row-level security as setup in step 1 and 2

Why not using current data sharing features?
Current Holistics data sharing features are fine for internal data sharing or ad hoc sharing. But when you want to share dashboards at scale, you want something more robust and automatable.

Setting for each dashboard the permissions seperately, is dangerous and prone to error. And require each person that wants to see a
Dashboard to have a Holistics account is a bit overkill.

This kind of a feature can be seen as an upgrade to the current Sharable Links feature. The benefits when having this future is high scalability and security!

#2

Current Holistics data sharing features are fine for internal data sharing or ad hoc sharing. But when you want to share dashboards at scale, you want something more robust and automatable.

Thank you @Abdel. We already have a Shareable Links (with pw) concept. What do you see the difference between that and this? From where I stand, the 2 scenarios are not much different in term of security?

I suppose one key benefit you’re looking for is it handles the “email password to guests” part automatically, hence reducing the logistics involved?

#3

Hi @huy,
Well, the difference is huge, I will explain why.

When you create a sharable link, you will need to do manually for each dashboard:

  • set row-level-permissions
  • send the password on a secure way to the end user
  • send the link to the end user

In the proposed approach

  • you set permissions using user attributes or email in the dataset
  • by asking for an email, you directly benefit from automatically applying row-level security, and let Holistics send the email with the password
#4

Thank you Abdel. I see what you mean now. This is kind of like the “Guest accounts” concept in Notion and Slack alike.

Basically the use case is to share a specific dashboard to a person outside of the company (employee of a partner company), and the current 2 solutions are not ideal for it:

  • Giving them a proper, full Holistics username is risky.
  • Creating a password-enable shareable link is also risky and difficult to maintain

Do I get that correctly?

#5

Hi @hung.nguyen,

That is completely correct!

#6

Hmm, perhaps Holistics embedded analytics can help solve this case, you might want to take a look at Embedded Analytics - Permission Settings | Holistics Docs. It gives you complete flexibility and scalability to control the data access from your back-end. You can even integrate the dashboards with your own authentication system, the downside is that it requires more work from the engineering side.

#7

Hi @anthonytd ,

Thank you.
I don’t think that is the right solution for this use case.

Having a guest type of account, can benefit a broad scala of use cases. But anyway, I will wait for comments of other people. If more people like to have this kind of feature, it might be good to develop it

#8

What might help by the way, is to have an additional “system attribute” that can’t be changed once it is there.

For example, I would want to provision users from an Identity Provider. There I map each user email to an Organization.
In Holistics the user would automatically get system-attribute h_email. But what if I could also give them another attribute like s_org that is controlled from the identity provider.
That attribute would then be used to filter rows only for that specific user based on the mapped attribute.

This will bring a better security, as those attributes are managed in one place, and synced to Holistics. This avoids any human error by maintaining the attributes manually