Summary

The current authorization and sharing for Renku 2.0 model has a few issues, most importantly, key instances where users need to be able to link data connectors but they cannot. The root of these issues is that in the current model, authorization and sharing are conflated: linking a data connector is over-loaded with an authorization implication. The result is that there are situations when sharing is unnecessarily limited (just because you can see a data connector doesn’t mean you can link it to another project), and other situations where your authorization controls are limited (you cannot create a ‘hidden’ data connector in a collaborative project for personal use).

The purpose of this pitch is to separate these two concerns of authorization and sharing. This is accomplished by allowing projects to serve as owners of components (i.e. data connectors). This solution will simplify how sharing works on RenkuLab, and also clear away current limitations where we are backed into a corner due to sharing and authorization being intertwined.

🤔 Problem

A refresher on how linking data connectors currently works

Data connectors exist independently of projects, and can be linked to one or more projects in order to be used in those projects.

In order to link a data connector to a project, at least one of the following conditions have to be true:

• The data connector is public
• You have the editor role or above on the data connector. This role is granted by the namespace where the data connector lives.

There are 2 types of data connector membership:

• Inherited membership: A person has access to the data connector by being a member of the data connector’s namespace (user or group). For more details, see Groups and Role Inheritance.

• Linked membership: In a project where the data connector is linked, all direct members of the project get the viewer role on the data connector.

  <aside> <img src="/icons/info-alternate_gray.svg" alt="/icons/info-alternate_gray.svg" width="40px" />

  The linked membership rule ensures that all members of a project can use a data connector that is linked to their project, regardless of the access to the data connector. In other words, this rule prevents the situation where project member A adds data connector X to the project, but project member B doesn’t have access to the data connector, so cannot use it in the project session.

  </aside>

For our full documentation on permission for data connectors, please see Data Connector Permissions.

Gosh that’s complicated! How did we arrive here?

We want data connectors to be reused in multiple projects, and we want to track data connector usage across those projects. Therefore, we want to offer the ability to link a single data connector to multiple projects. And in general, we want to elevate data as a ‘first class entity’ on RenkuLab, so you can have a data connector without a project at all.

→ Therefore, it makes sense for data connectors to exist independently of projects. It seems most intuitive for data connectors to work in the same way as projects, where they are namespaced in either user or group namespaces.