This approach works extremely well with a static user list for RTC.
Has there been any progress towards adding “allowed users” on runtime with the API so we don’t have to restart JH each time there is a new user joins?
I’ve been tracking the following issues related to this:
opened 08:11AM - 07 Apr 22 UTC
enhancement
### Proposed change
For sharing and user-initiated collaboration, I think we … want the ability for users to _grant_ other users permissions. Right now, to collaborate, admins must grant minimum sharing permissions _at all times_. This works for protyping purposes, and single-group deployments, but not in general
For simplicity, the first implementation of RBAC only allows roles to be defined in config. That means we always reconcile all role assignments to reflect config - roles cannot be created without restarting the hub, and their definitions only reside in config.
Example use cases:
1. start a server (e.g. a dashboard) and make it accessible by all users, unlike the user's default server (https://discourse.jupyter.org/t/refining-server-scopes-in-role-definitions/13760)
2. user grants limited (e.g. read-only) collaboration access to their current server, _without_ requiring that the other user have that access all the time. The user should be able to revoke permissions they have granted.
The challenges are in reconciliation with config:
1. if we can grant access during runtime, we can't revert to config at each restart. We have to recognize what changes are from changed config and what changes are from runtime, priorities, etc.
2. what's the difference at startup between a role deleted from config (should be deleted) and a role created during runtime (should be left alone)?
### Who would use this feature?
Deployments that want selective and user-controlled collaboration.
### (Optional): Suggest a solution
- REST API for managing roles, role assignments
- need a way to track role changes from config vs runtime to avoid making a mess during hub startup. A single flag on the role might be the simplest way to track - config-managed roles could be read-only via API.
- need to track roles 'owned' by users
- Users may _create_ roles, granting other users permissions
- something like `oauth_allowed_roles`, but for users to govern which permissions they can grant others
opened 01:27PM - 10 Feb 23 UTC
enhancement
### Proposed change
Introduce a first-class concept of a 'share', as distinct… from general 'roles', to address the use case of "I want to easily grant someone access to my server and then maybe revoke it later".
For users granting access, I've long had in mind #3858 as the solution, which would allow users to create roles and role assignments at runtime, _one_ application of which could be granting someone else access to their server. But after testing out sharing and RTC use cases, I increasingly think that's not going to be enough. Even when we get to that (and I think we should still do that), we're probably going to want 'share' as a first-class concept.
### Alternative options
Implement fully generic roles, as described in #3858. This will _technically_ enable the same thing (likely _more_ things), but because it's a generic permissions-granting system, it may be complicated to implement a simple sharing access UI on top.
### Who would use this feature?
JupyterHub deployments where _users_ are in control of granting other users' access to their servers.
### (Optional): Suggest a solution
Introduce a first-class `share` entity in the JupyterHub, with REST API for create/delete/list.
Shares would:
- be owned by a specific user
- target a single, specific server
- be listable and revocable
- expire
- implementation-wise, ultimately be a restricted and runtime-defined role assignment
- grant the minimal `access:servers!server=...` permission
- (maybe) optionally grant additional `!server=`-filtered permissions. This will be necessary for e.g. read-only access. It's unclear to me what level of control will be needed on that.
- (maybe) optionally apply on wider filters, such as `!user`. I plan to go with "not in the first implementation" on this one.
Implementation-wise, this would effectively be a runtime role assignment, but with a higher-level API for creating/managing them, because they would be specifically used for accessing services (i.e. a 'share' couldn't be used to grant admin access). In addition to the new APIs and database entries for managing share objects themselves, the only change should be in resolving the permissions for a specific user to add Shares, which will be treated identically to Roles.
Features could include:
- 'share with link' where a special link could be used to _claim_ sharing access without the sharer needing to invite users by name (this would be the exact jupyterlab-link-share experience but with full JupyterHub permission controls)
- expiration, for short-lived one-time sharing session
- revoke sharing permissions by multiple keys, such as:
- all shares for this server
- a specific sharing link, and any access granted thereby
- individual sharing permissions
manics
September 27, 2023, 9:17am
22
You can already add users via the API without restarting the hub. If you’re using pre-defined/shared roles this should be enough.
If you want to create per-user roles dynamically you’ll need to wait for the issue you linked to be resolved. There’s an open PR:
jupyterhub:main ← vladfreeze:role_handlers
opened 09:31AM - 15 Jul 22 UTC
I needed to dynamically add/edit roles and permissions of groups and therefore c… reated an endpoint which allows the admins to create, edit or delete roles using JupyterHub's REST API.
It can be accessed by using the api url with the /roles/rolename path and supports the GET, POST, PUT and DELETE requests.
but it needs more work, including to resolve conflicts between changes in the static vs dynamic config.
minrk
October 2, 2023, 10:33am
23
Has there been any progress towards adding “allowed users” on runtime with the API so we don’t have to restart JH each time there is a new user joins?
I’m working on it! I hope to have a draft pretty soon. The ownership/associations are proving a bit tricky (are the shares owned by the ‘server’ or the user who created them? How should I be able to list ‘my’ shares? etc.).
@manics @minrk
Thanks for the update and info!