Feature: new permission model

[arikfr]

This pull request implements new permission model (explained below) and interface for adding groups and associating members with groups. It implements most of the functionality of #636, except for per query permissions.

New Permission Model

Until now each user had one or more groups associated with him, from which he derived the actions he permitted to do in the system (execute query, run query, create dashboard, etc). With this pull request I add another dimension to this: each datasource is associated with the groups that can access it, where access is either full access or just read access (read existing queries).

This simple model should allow a variety of use cases, but in the future I can see two enhancements to it:

• Per query permissions, i.e. the ability to extend the access scope of a single query, vs. the whole data source. It's actually not a large change in the code base, and mainly about adding the API to extend the groups and the UI.
• Ability to share a URL that gives access to a single query, similar to the embed functionality @akariv implemented in Feature: ability to embed visualizations in external sites #664.

How does it work?

• As before, each user belongs to one or more groups. By default each user joins the "Default" group. So the common datasources, should be associated with this group.
• Once this merged, each datasource will be associated with one or more groups. Each connection to a group will define, whether this group has full access to this data source (view existing queries and run new ones) or view only access, which allows only viewing existing queries and results.
• Any dashboard can contain visualizations from any data source (as long as the creating user has access to them). When a user who doesn't have access to some visualization (because he doesn't have access to the datasource) opens a dashboard, he will see that there is a visualization there but won't see the details.

What if I want to limit the user to only some tables?

The idea is to leverage your database's security model, and hence create a user with access to the tables/columns you want to give access to, create a datasource that is using this user and then associate it with a group of users who need this level of access.

Previously each group had a tables property, which was used for a similar purpose, this is now removed. It wasn't fully safe, and I believe it's better to rely on the database's security model. If you were using this, please update your datasources accordingly.

Organizations

In this pull request I'm also introducing "Organizations", which is a way to partition data in your re:dash instance beyond groups. While groups allow you to manage who can access individual queries/datasources, the users and dashboards are visible to everyone. With an organization you can create a "silo", where each organization has its own users, datasources, dashboards and groups.

It's irrelevant to most of the users, and I tried to minimize the impact on the source code. Its purpose is to serve as basis for a hosted re:dash service (SaaS), I'm going to introduce (I will share more details soon).

Backward Incompatible Changes

There are some backward incompatible changes in this pull request:

• As mentioned above, the tables property in groups (and feature) was removed. If you used this, please create the relevant datasources when migrating.
• If you had some additional groups beyond the default ones, default and admin, I recommend reviewing the changes and making sure that they don't affect you.

(Closes #580)

[toyama0919]

Awesome😍

[MaxPleaner]

Curious if this will be added to the AWS images soon? I just launched mine and am trying to figure out how to implement access control .

[arikfr]

I'm planning to create new images tomorrow. But until then you can just run
the upgrade process (documented in the docs).

On Wednesday, 20 January 2016, Max Pleaner notifications@github.com wrote:

Curious if this will be added to the AWS images soon? I just launched mine
and am trying to figure out how to implement access control .

—
Reply to this email directly or view it on GitHub
#724 (comment).

Arik Fraimovich

[Xangis]

Please be sure to update system patches on your AMI. The existing AMIs are old enough that they have some unpatched vulnerabilities.

[arikfr]

@Xangis sure. I'm always taking the latest Ubuntu base image.

[TonyStarkBy]

When a user who doesn't have access to some visualization (because he doesn't have access to the datasource) opens a dashboard, he will see that there is a visualization there but won't see the details.

It will be great if it will be possible to set access to whole dashboard by groups.

Example:

• I have project A and project B, for each project i have dashboards: dashboard-A and dashboard-B
• I have two groups with users: group-mangagers-project-A and group-mangagers-project-B
• i want to restrict access to this dashboards by user group

[TonyStarkBy]

And one more thing - "read only" status to group. Users in this group can't edit/view SQL source :)

[arikfr]

@TonyStarkBy

While both groups will see that both dashboards exists, each group will be able to see the contents of only its own dashboards.

And one more thing - "read only" status to group. Users in this group can't edit/view SQL source :)

This already exists: you can set that a group has permission to only view queries on some (or all) data sources.

[TonyStarkBy]

This already exists: you can set that a group has permission to only view queries on some (or all) data sources.

I already try this, but users can view SQL query (only button "Execute" was disabled) and can edit charts.

[teguhn]

Is there any documentation on how to create "Organizations"? Thanks