[ENH] - Implement App permissions/Sharing

[aktech]

Feature Description

Fine-grained permissions on the ability to create and share an app.

Possible Permissions

App Sharing

• A user can share an app to user(s) in the group they are themselves in or any user in the groups they have permission to share.
• A user can share an app to group(s) they have permission to share.
• A user can share an app to the internet (without any Authentication)
• A user cannot share an app

App Creation

• A user (or group) can create an app
• A user (or group) cannot create an app

Notes:

• All the shared apps, will always be running as the user who created the app
• If an app has been shared with a user, they will have the ability to restart it in case its stopped (e.g. idle culled). The user will have no permissions to edit the app, i.e. the app will be started with same configuration as it was created with.

Implementation Steps / Tasks

• Remove sharing / displaying all apps to all users
• Use JupyterHub 5.x APIs to share an app, implement the following functionality in the HubClient ([ENH] - Implement JupyterHub 5.x sharing APIs in the hub client #185):
  • Grant shared access to a list of users and/or a list of groups API Docs
  • Revoke all shared access to a given server API Docs
  • Fetch shared apps (servers) for a given user API Docs
• Try using latest JupyterHub (latest main) with Nebari to see if there is anything that needs to be done to add support for latest (unreleased) JupyterHub. [ENH] - Move to JupyterHub 5.x (unreleased) to support app sharing #159 [ENH] - Move to JupyterHub 5.x (unreleased) nebari#2330
• Add API endpoints for ([ENH] - Implement API endpoints to get user/groups to share app with #186):
  • list of users (to share an app with)
  • list of groups (to share an app with)
• Make JupyterHub use groups and roles from Keycloak ([ENH] - Make JupyterHub use groups and roles from Keycloak nebari#2308), see relevant links:
  • https://discourse.jupyter.org/t/is-jupyterhub-rbac-groups-the-same-as-oauth-groups/22412/3
  • https://discourse.jupyter.org/t/jupyterhub-keycloak-auth-and-ldap-user-groups/22512
  • Working configuration for generic authenticator with Keycloak jupyterhub/oauthenticator#107
  • https://discourse.jupyter.org/t/oidc-rbac-possible-to-map-users-to-groups-and-groups-to-roles-where-users-and-groups-are-defined-by-oidc/22426
• Add functions to figure out the permissions to create and share an app. After we make JupyterHub use groups and roles from Keycloak, we will be able to see the roles assigned to a user via keycloak and those roles when attached to a group or user, will dictate if a user can share (or create) apps or not. After this we will be able to send the roles for a user to the frontend, then it can enable and disable ability to share or not share apps. In backend we need to add a check to make sure a user must have appropriate roles to be able to share. The following three scenarios are possible:
  • nobody or everybody can share apps
  • some people can share apps
  • some people can create an app
    This is slightly dependent on: [META] Permissions overhaul nebari#2304

Notes

• jhub-apps isn't supposed to be tightly tied with Nebari, that's why we're using JupyterHub constructs / models to implement everything, for example when not used with Nebari, it would not have keycloak, but it will have users, groups and roles anyway, which means our logic doesn't care about how jhub-apps is deployed. Also, cases where we specifically need to handle a usecase for Nebari, which could be different for a non-kubernetes deployment of jhub-apps we handle that by exposing a configuration option, which can be configured via jupyterhub_config.py using JAppsConfig, See conda_envs for example, which is set to a function in Nebari, which fetches conda envs from conda-store, but any other deployment of jhub-apps would not need to worry about it.
• The way we will define roles in Nebari will depend the implementation of [META] Permissions overhaul nebari#2304

[kcpevey]

REDACTED - The scope of this issue now includes the suggestion from this comment. I've removed it here to keep this issue readable/less confusing.

[kcpevey]

If a user is shared an app, they have the ability to start it in case its stopped (e.g. idle culled), but have no permissions to edit the app, i.e. the app will be started with same configuration as it was created with.

To make this a little more clear - If an app has been shared with a user, they will have the ability to restart it in case its stopped (e.g. idle culled). The user will have no permissions to edit the app, i.e. the app will be started with same configuration as it was created with.

A user can create an app

Do we want the ability to control this at the group level as well? Or is that a v2.0 implementation?

[krassowski]

Cross linking previous discussion in #110

I do not see anything about impersonation. Do I correctly assume that users visiting shared apps will still be able to act as the author of the shared app and their activity will be logged as that person (rather as themselves?). My understanding was that using "collaborative users" is required to solve impersonation, but if the proposal in here solves it by itself its even better!

[aktech]

I do not see anything about impersonation.

It's probably not very explicit, as mentioned in the notes above: "All the shared apps, will always be running as the user who created the app."

Do I correctly assume that users visiting shared apps will still be able to act as the author of the shared app and their activity will be logged as that person (rather as themselves?)

Yes correct, regarding the activity logging, I am not sure will have be check JupyterHub's sharing docs.

My understanding was that using "collaborative users" is required to solve impersonation, but if the proposal in here solves it by itself its even better!

We're not solving impersonation (as in shared notebook apps) yet, as that's beyond the scope. The main use case of app sharing is to share panel, streamlit, bokeh, custom, etc apps and not jupyter notebook server. What we saw in #110 was consequence of #138, the original intention was never to share notebook server/app (even though it is possible to do so by creating a custom jupyter notebook server app and sharing that).

When we are sharing panel, streamlit types apps the user with whom the app is shared is actually indeed impersonating in the sense that those apps have access to the original author's data (home directory in Nebari).

[aktech]

Do we want the ability to control this at the group level as well? Or is that a v2.0 implementation?

All permissions will be configurable at user as well as group level, made it explicit now.

[aktech]

As per @dharhas

Unless someone is an admin they will only be able to share to people in the groups they belong to
Non admins should not be able to share to an individual who is not in a common group with them.

I was thinking that someone in non-admin group can potentially have permissions (granted explicitly) to share in a group other than the group they are present in, like say

• superadmin
• admin
• developer
• analyst
• viewer

Say superadmin and admin both are able to share apps to people in any group and say developer can have permission to share to people in analyst group.

[dharhas]

Actually, we need to move away from overarching groups like developer, analyst etc. And moves to groups and roles within groups.

Let's take an example of a user called Mary. Mary belongs to three groups - research, data-science and project-orion

Mary has app sharing permission in the research and data-science groups but does not have permission to share apps in the project-orion group.

When she chooses to share an app she will be able to select any combination of the following.

• individuals from the research or data-science groups.
• the research group
• the data-science group

She should not be able to share with:

• the project-orion group
• individuals in the project-orion group (unless they are also in either the data-science or research groups)

From the UI/UX pov, the backend will make available the available groups that can be shared with and probably a way to search for individuals. The exact logic of fetching those lists will be in the backend.

[aktech]

Actually, we need to move away from overarching groups like developer, analyst etc.

This is beyond the scope of this ticket, the relevant issue is: nebari-dev/nebari#2304 The groups I mentioned in the example are only for demonstration purpose, not implying them as the ones we're going to have them.

And moves to groups and roles within groups.

Same, the implementation for this will be proposed in nebari-dev/nebari#2304

Your example seems to be echoing what I said in the above comment (ignore the group names and assume all permissions are explicitly specified as in a group/individual is explicitly given permission to share in a group)

From the UI/UX pov, the backend will make available the available groups that can be shared with and probably a way to search for individuals. The exact logic of fetching those lists will be in the backend.

Yes correct, see 4th todo in the "Implementation Steps / Tasks" section in the issue description.